Designing an AI-Powered Retail Intelligence Platform on AWS Serverless
Listen to this article
Browser text-to-speech
The Problem: Retail Intelligence at the Edge
India has over 12 million kirana stores — small, independent retailers who form the backbone of the country's retail economy. Large retail chains have enterprise intelligence platforms: demand forecasting, inventory optimisation, pricing analytics. The neighbourhood kirana store has a notebook and a WhatsApp group.
The gap is not technology awareness. It is access. Enterprise tools assume desktop dashboards, structured workflows, and dedicated operators. None of that maps to how a kirana store owner actually works — they are on their feet, serving customers, managing suppliers, and making decisions on the move.
The question was not "how do we build another retail analytics dashboard?" It was "how do we bring AI-powered retail intelligence to people who will never open a dashboard?"
Architecture Decisions
Three constraints shaped every design choice:
1. Channel-first, not dashboard-first. The primary interface had to be WhatsApp — the tool retailers already use daily. A React dashboard exists for analytics and management, but it is the secondary channel. Voice input adds a third. The intelligence layer serves all three through a single API surface.
2. Serverless and event-driven. A platform targeting small retailers cannot carry fixed infrastructure costs. Every component needed to scale to zero when idle and scale elastically under load. No servers to manage, no capacity to provision.
3. AI as a composed capability, not a single model. Different intelligence tasks require different AI services. Generative insights, demand forecasting, entity extraction, and speech processing are fundamentally different problems — each gets the right tool.
Platform Architecture
The Channel Layer
Three input channels converge on a single API Gateway:
- WhatsApp Bot — Retailers send natural language messages: "Maggi price 12 rupees" or "What is the forecast for Parle-G?". The system extracts entities, generates insights, and responds conversationally
- React Dashboard — Full analytics interface with demand forecast visualisations, signal monitoring, store management, and an AI query interface
- Voice Input — Speech-to-text via Amazon Transcribe, enabling voice-driven data capture for retailers who prefer speaking over typing
The critical design insight: the intelligence layer is channel-agnostic. The same Lambda functions, the same AI pipeline, the same data models serve every channel. Adding a new channel means adding an adapter, not rebuilding the intelligence.
The Orchestration Layer
Thirteen Lambda functions handle discrete responsibilities — store management, signal ingestion, enrichment, forecasting, insights generation, notifications. EventBridge provides event-driven orchestration between them.
The serverless model means the platform costs virtually nothing at rest. During the hackathon demo, the total AWS bill was $3–5 — for a working prototype with multiple channels and real-time analytics.
The AI Services Layer
This is where the architecture becomes interesting. Four AWS AI services, each solving a different class of problem:
Amazon Bedrock — Generative AI for two distinct workflows. First, natural language insight generation: given a retail signal (price change, stock movement, competitor activity), Bedrock generates actionable summaries with key findings and recommendations. Second, Retrieval Augmented Generation (RAG) using Titan Embeddings — context-aware answers grounded in the platform's own data, not general knowledge.
Amazon SageMaker — DeepAR time-series forecasting for demand prediction. Given historical sales patterns, location context, and seasonal signals, the model produces demand forecasts with confidence intervals. This is not generative AI — it is classical ML, purpose-built for the specific structure of time-series prediction.
Amazon Comprehend — NLP entity extraction from unstructured retailer messages. When a WhatsApp message arrives, Comprehend identifies product names, prices, quantities, and locations — turning conversational text into structured data the pipeline can act on.
Amazon Transcribe — Speech-to-text conversion for voice inputs. Combined with Comprehend for entity extraction, this creates a voice-driven data capture pipeline — a retailer speaks, the system understands.
Each service is independently replaceable. If a better forecasting approach emerges, swap the SageMaker component — the rest of the architecture does not change.
The Data Layer
DynamoDB provides the operational data store — four tables covering stores, products, signals, and forecasts. The schema is designed for the access patterns, not for relational normalcy. Single-table design principles apply where it makes sense.
S3 serves as the data lake — raw signal data, processed embeddings for RAG, forecast training data, and audit logs. The separation between operational and analytical data is clean.
Amazon Location Service adds geo-context — geocoding retailer locations, enabling location-based analytics, and providing spatial intelligence for regional demand patterns.
The WhatsApp Decision
This deserves its own section because it represents a design philosophy, not just a feature choice.
Enterprise software defaults to building dashboards. Dashboards assume the user will come to you. In India's retail ecosystem, that assumption fails. A kirana store owner will not log into a web application between serving customers. But they will reply to a WhatsApp message.
The WhatsApp integration means:
- Minimal onboarding friction — no app to install, no account to create, no new interface to learn
- Natural language interaction — retailers describe what they see in their own words
- Asynchronous intelligence — insights and forecasts are delivered as messages, consumed when convenient
- Network potential — retailers already share information in WhatsApp groups; the bot could integrate naturally into that ecosystem
Meeting users where they are, rather than where enterprise software wants them to be — that is the design principle.
Security and Cost Architecture
Authentication flows through Amazon Cognito with role-based access control. API Gateway enforces authentication on every endpoint. No PII is sent to AI models — the pipeline is designed for data privacy by default.
Cost controls are built into the architecture, not bolted on:
- Aggressive caching (24-hour TTL) for Bedrock calls to prevent redundant inference
- Manual triggers for expensive operations during early adoption
- CloudWatch alarms at $10/day thresholds
- Token usage tracking per AI service
- Serverless scale-to-zero eliminates idle costs entirely
What the Platform Demonstrates
| Capability | Implementation |
|---|---|
| Multi-channel AI | Single intelligence layer serving WhatsApp, web, and voice |
| Generative + Classical ML | Bedrock for insights, SageMaker for forecasting — right tool for each task |
| Serverless architecture | 13+ Lambda functions, event-driven, scale-to-zero |
| RAG workflow | Context-aware queries grounded in operational data |
| Voice-driven capture | Transcribe + Comprehend for hands-free data entry |
| Cost discipline | $3–5 total demo cost for a full-featured AI platform |
Closing Thought
The most interesting architectural problems are not about technology selection. They are about understanding the context well enough to question defaults — why a dashboard when the user lives on WhatsApp? Why one model when four services each solve a different problem better? Why provision servers when serverless matches the cost profile?
Good architecture starts with the right questions, not the right tools.
Originally prototyped during the AI for Bharat Hackathon (AWS x Hack2skill, June 2026).