Commerce
Commerce
E-commerce platforms, supply chain, retail technology — the systems powering India's $200B+ digital commerce ecosystem and the world's fastest-growing retail market.
$70B+
India E-commerce 2024
500M+
Online Shoppers by 2030
10 Min
Quick Commerce Delivery
$350B
India E-comm Projection
What Engineers Miss When They First Enter Commerce
Commerce technology is deceptively easy to describe and genuinely hard to build correctly. The customer sees a product, adds it to a basket, pays, and receives a delivery. The engineering team sees inventory reservations racing against concurrent shoppers, payment authorisations that expire while fraud checks run, warehouse pick tasks that depend on carrier pickup schedules that depend on weather that changes at 4pm, and a return flow that has to work just as well as the forward flow even though most teams build it last and staff it least.
India's e-commerce market adds a layer of complexity that has no equivalent anywhere else. Peak events like Flipkart's Big Billion Days or Amazon's Great Indian Festival move more transaction volume in 48 hours than most markets see in months. The engineering problems that appear during these events — inventory contention at the millisecond level, payment gateway saturation, notification fan-out across hundreds of millions of push tokens, logistics slot exhaustion — have shaped the architecture of India's commerce systems into some of the most performance-tuned infrastructure in the world.
Quick commerce introduced another category of problem: the 10-minute delivery SLA means that every system in the chain — search, inventory, assignment, picking, dispatch, last-mile — has to be not just correct but fast enough that no single step absorbs the entire buffer. Engineers who come from standard e-commerce backgrounds find that margin for error in quick commerce is far thinner than anything they've worked with before.
What Teams Actually Do Day To Day
- 1Maintain the inventory ledger across thousands of SKUs per warehouse with consistency guarantees strong enough to prevent overselling during concurrent flash sale traffic, while soft-reservation timeouts release stock back into the pool for customers who abandon checkout.
- 2Build and tune the search relevance stack that surfaces the right products when users type partial queries in three languages at 100,000 requests per second, balancing real-time inventory signals against personalisation models that run on stale data.
- 3Integrate with 8-12 payment partners simultaneously — UPI apps, card networks, BNPL providers, wallets — each with different timeout characteristics, retry behaviors, and reconciliation file formats that have to be normalised into a single internal payment state machine.
- 4Operate the order lifecycle through edge cases that the happy path never encounters: partial cancellations after split-shipment dispatch, refunds for orders that shipped from sellers who have since been suspended, address corrections after the warehouse has already printed the label, and replacement flows where the original item has gone out of stock.
- 5Build seller tooling that processes the other side of every consumer-facing feature — catalog ingestion, pricing rules, SLA enforcement, penalty calculations, payout reconciliation, and the operations dashboards that let account managers catch problems before sellers escalate.
One End-to-End Transaction: A Flash Sale Purchase on a Marketplace
A purchase during a high-traffic sale event exercises every critical path in commerce infrastructure simultaneously. This walkthrough follows a single add-to-cart to confirmed shipment across the systems that participate.
Customer adds item to cart during sale window
The cart service receives the add request. Before accepting it, inventory availability is checked — not against a database row lock but against an atomic counter in Redis, because the database cannot handle the concurrent update rate during a flash sale peak.
Systems Involved
Cart service, Redis inventory counters, product catalog cache
Where It Usually Breaks
Race conditions between concurrent add-to-cart requests for the last unit can allow multiple customers to believe they have reserved stock. The fix is atomic decrement with a floor check.
Checkout session opens and soft reservation is created
When the customer starts checkout, a soft reservation is created with a TTL — typically 10-15 minutes. This hold prevents other customers from taking the same unit while preserving the ability to recover inventory if the customer abandons. The reservation creates an event that the inventory service consumes to track committed versus available stock.
Systems Involved
Checkout service, inventory reservation service, event bus
Where It Usually Breaks
If the reservation TTL is too short and checkout takes longer than expected (slow payment flow, address validation delay), the customer reaches payment confirmation to find their item is no longer available.
Payment is initiated and authorised
The payment service routes to the selected method. For UPI, the customer is redirected to their PSP app. For cards, the request goes through the payment gateway to the issuing bank. The authorisation response arrives asynchronously — the checkout service polls or receives a webhook.
Systems Involved
Payment service, payment gateway, UPI PSP, issuing bank
Where It Usually Breaks
Webhook delivery failures during high traffic mean the order processing service may not receive the payment confirmation, leaving orders stuck in a pending state that requires reconciliation with the gateway later.
Order is created and inventory is hard-committed
Once payment authorises, the OMS creates the order record. The soft inventory reservation converts to a hard allocation — the seller's available count decrements permanently. The order event fans out to the seller portal, the WMS pick task queue, and the notification service.
Systems Involved
Order Management System, inventory service, WMS, notification service, seller portal
Where It Usually Breaks
If the OMS write succeeds but the inventory hard-commit fails (downstream timeout), the customer has an order with no stock allocation. The reconciliation job must catch and resolve this before the warehouse tries to pick a non-existent unit.
Warehouse picks and packs the item
The WMS receives the pick task, assigns it to an operative based on their location in the warehouse and the item's slot. The operative scans the item to confirm it matches the task. Packing station scans generate the shipment record and call the carrier API to get a tracking number and print a label.
Systems Involved
WMS, pick task service, packing station, carrier API
Where It Usually Breaks
Inventory discrepancies between the WMS and physical stock can cause pick failures — the operative goes to the slot and finds nothing there. These exceptions require manual investigation and a customer re-order or substitute fulfillment.
Carrier collects and delivers
The carrier collects the sealed package, scans it into their system, and moves it through their sortation network. Tracking events published by the carrier's API are consumed by the retailer's notification service and surfaced to the customer through the app.
Systems Involved
Carrier sortation system, carrier API, tracking event consumer, notification service
Where It Usually Breaks
Carrier API rate limits during peak periods can delay tracking event processing. Customers who check their order status see stale information, generating support tickets despite the physical package moving normally.
Technology Architecture — How Commerce Platforms Are Built
The diagram below reflects how production Commerce systems are structured at scale — nine layers from client channels through edge security, API gateway, domain microservices, polyglot data stores, async event streaming, analytics, external partners, and cloud infrastructure. Solid arrows show synchronous REST/gRPC calls; dashed arrows show async event flows via Kafka or a message queue.
Industry Players & Real Applications
🇮🇳 Indian Companies
Flipkart
E-commerce Marketplace
India's largest e-commerce platform — Walmart-owned, HQ Bengaluru
Amazon India
E-commerce Marketplace
India operations of global Amazon — Prime, Seller Central
Meesho
Social Commerce
Social commerce for Bharat — 150M+ customers, mostly Tier 2/3
Blinkit (Zomato)
Quick Commerce
10-minute grocery delivery — dark store model
Zepto
Quick Commerce
10-minute delivery — fastest-growing quick commerce startup
JioMart
Omnichannel
Reliance's O2O commerce — offline kirana + online integration
Nykaa
Vertical E-commerce
Beauty and fashion e-commerce — India's first unicorn with women founder
Delhivery
Logistics
India's largest logistics company — tech-first approach
🌍 Global Companies
Amazon
E-commerce & Cloud
World's largest e-commerce platform — AWS, Alexa, Prime
Alibaba
E-commerce Marketplace
China's e-commerce giant — Taobao, Tmall, AliExpress
Shopify
Commerce Platform
Commerce platform for 2M+ merchants — DTC enabler
Walmart
Retail
Largest retailer — omnichannel, acquired Flipkart for $16B
Stripe
Payment Infrastructure
Payment infrastructure powering millions of commerce businesses
🛠️ Enterprise Platform Vendors
Shopify
SaaS Commerce
End-to-end commerce platform — storefront to fulfillment
SAP Commerce Cloud
Enterprise Commerce
Enterprise commerce and order management
Magento (Adobe Commerce)
E-commerce Platform
Open-source e-commerce platform
Manhattan Associates
WMS/SCM
WMS and supply chain — used by Flipkart, large retailers
Core Systems
These are the foundational systems that power Commerce operations. Understanding these systems — what they do, how they integrate, and their APIs — is essential for anyone working in this domain.
Business Flows
Key Business Flows Every Developer Should Know.Business flows are where domain knowledge directly impacts code quality. Each flow represents a real business process that your code must correctly implement — including all the edge cases, failure modes, and regulatory requirements that aren't obvious from the happy path.
The detailed step-by-step breakdown of each flow — including the exact API calls, data entities, system handoffs, and failure handling — is covered below. Study these carefully. The difference between a developer who “knows the code” and one who “knows the domain” is exactly this: the domain-knowledgeable developer reads a flow and immediately spots the missing error handling, the missing audit log, the missing regulatory check.
Technology Stack
Real Industry Technology Stack — What Commerce Teams Actually Use. Every technology choice in Commerceis driven by specific requirements — reliability, compliance, performance, or integration capabilities. Here's what you'll encounter on real projects and, more importantly, why these technologies were chosen.
The pattern across Commerce is consistent: battle-tested backend frameworks for business logic, relational databases for transactional correctness, message brokers for event-driven workflows, and cloud platforms for infrastructure. Modern Commerceplatforms increasingly adopt containerisation (Docker, Kubernetes), CI/CD pipelines, and observability tools — the same DevOps practices you'd find at any modern tech company, just with stricter compliance requirements.
⚙️ backend
Java / Spring Boot
Core commerce services — OMS, catalog, pricing at Flipkart, Amazon
Go
High-throughput microservices — inventory, search ranking
Python
ML for recommendations, demand forecasting, fraud detection
Node.js
API gateway, real-time features, BFF layer
🖥️ frontend
React / Next.js
Storefront, seller portal, admin dashboards
React Native / Flutter
Mobile shopping apps
🗄️ database
MySQL / PostgreSQL
Transactional data — orders, customers, inventory
MongoDB
Product catalog — flexible schema for diverse categories
Elasticsearch
Product search — the most critical feature of any e-comm
Redis
Cart, sessions, inventory counts, flash sale locks
Apache Kafka
Order events, inventory updates, real-time analytics
☁️ cloud
AWS
Amazon India naturally; Flipkart uses private cloud + AWS
Google Cloud
Meesho, Nykaa — GCP ecosystem
Azure
Enterprise retail solutions
Interview Questions
Q1.How do you handle inventory during a flash sale to prevent overselling?
Preventing overselling in a flash sale requires: 1) Pre-event inventory staging — move stock to a fast cache (Redis) from DB. 2) Atomic decrements — use Redis DECR command which is atomic, preventing race conditions. 3) Soft reservation + TTL — on cart add, reserve with a 10-minute TTL; release if checkout doesn't complete. 4) Queue-based ordering — funnel all purchase requests through a queue (Kafka), process sequentially per SKU. 5) Optimistic locking at DB — use version numbers to detect concurrent updates. 6) Circuit breakers — if inventory service is overwhelmed, fail fast rather than oversell. Companies like Flipkart use pre-computed 'slots' so each purchase decrements from a pre-allocated bucket.
Q2.Design the architecture for a 10-minute delivery app (like Blinkit).
Quick commerce architecture key components: 1) Dark store network — small warehouse (2,000 sq ft) within 2-3 km of customer. 2) Real-time inventory per dark store — Elasticsearch for availability search filtered by location. 3) Assignment algorithm — assign nearest dark store with all items in stock. 4) Picking optimization — ML-trained picking path inside store to minimize pick time (SLA: 2-3 min). 5) Delivery partner assignment — nearest available partner via ride-matching algorithm (Haversine distance + travel time). 6) Dynamic ETA — continuously updated based on picker progress + rider location. 7) Hyperlocal search — catalog filtered by dark store inventory in real-time. Challenges: single-item orders (high delivery cost), weather disruptions, surge management.
Glossary & Key Terms
OMS
Order Management System — tracks orders from placement to delivery and returns
WMS
Warehouse Management System — manages inventory, picking, packing in warehouses
SKU
Stock Keeping Unit — unique identifier for each product variant
GMV
Gross Merchandise Value — total value of goods sold through platform (before returns)
Quick Commerce
Ultra-fast delivery (10-20 min) from hyper-local dark stores
Dark Store
Small urban warehouse serving only delivery orders, not open to walk-in customers
Marketplace
Platform model where third-party sellers list products (Flipkart, Amazon)
D2C
Direct-to-Consumer — brands selling directly without marketplace intermediary