Design an E-Commerce Platform (Amazon/Flipkart) — Cheat Sheet

An e-commerce platform is a composition of loosely-coupled services — catalog, inventory, orders, payments, and recommendations — each with distinct scaling and consistency requirements. The hardest problems are preventing overselling under concurrent load, processing orders as a distributed transaction across services without a two-phase commit, and making 300M products searchable in under 100ms.

• ✓Product catalog: browse, search, and view product detail pages
• ✓Shopping cart: add/remove items, persist across sessions
• ✓Checkout: place an order, which reserves inventory and initiates payment
• ✓Payment: process credit/debit cards and digital wallets (Stripe/Razorpay integration)
• ✓Order management: track order status (placed → confirmed → shipped → delivered)
• ✓Inventory management: sellers can update stock levels

• ✓Products in catalog: 300M
• ✓Orders (steady state): 100K / day ≈ 1.2 / sec
• ✓Orders (peak): 500K / day ≈ 6 / sec
• ✓Flash sale peak: ~10K orders / min ≈ 167 / sec (for 10 min)
• ✓Catalog reads vs writes: 100:1 (mostly browsing)
• ✓Storage per product: ~5 KB (metadata + images) → 300M × 5KB = 1.5 TB catalog DB

• ✓API Gateway / Load Balancer — Routes traffic to downstream microservices. Handles TLS termination, JWT authentication, and per-user rate limiting. Applies aggressive rate limits during flash sales to prevent stampede.
• ✓Product Catalog Service — Stores structured product data (title, description, attributes, images, price) in a relational DB (PostgreSQL) with read replicas. Publishes ProductUpdated events to Kafka which feed the Elasticsearch index and CDN-cached product pages.
• ✓Search Service (Elasticsearch) — Full-text and faceted search over 300M products. Supports filtering by category, price range, rating, and availability. Updated asynchronously via a Kafka consumer. Returns results in < 100ms for 95% of queries.
• ✓Inventory Service — The single source of truth for stock levels. Exposes reserve and release operations with optimistic locking. Uses Redis atomic operations for real-time stock counters during flash sales.
• ✓Cart Service — Maintains shopping cart state (userId → list of {productId, quantity, price snapshot}) in Redis with a 30-day TTL. Validates item availability on checkout but does NOT reserve inventory — reservation happens only at order placement.
• ✓Order Service — Orchestrates the checkout flow as a Saga. Creates an order record, triggers inventory reservation, triggers payment, and transitions order state. Handles compensation (inventory release, refund) if any step fails.

• ✓Pessimistic locking vs optimistic locking vs Redis for inventory → Redis atomic Lua script for flash sales; optimistic locking for steady state: Pessimistic locking serialises all writes on a product, destroying throughput under flash-sale concurrency. Optimistic locking is fine for < 20% retry rate but generates retry storms under extreme contention. Redis atomic decrement handles thousands of concurrent requests per second for the same SKU without contention.
• ✓2PC (two-phase commit) vs Saga for order distributed transaction → Saga (orchestration pattern): 2PC requires all participating services to hold locks until the coordinator decides, coupling availability. A Saga uses local transactions with compensating actions — each service commits independently. The Order Service is the sole orchestrator, making failure handling explicit and debuggable.
• ✓Synchronous vs asynchronous search index updates → Asynchronous via Kafka CDC (Debezium): Synchronously writing to Elasticsearch on every catalog update would couple the Catalog Service to Elasticsearch availability and add latency. CDC via Debezium → Kafka decouples the two, allows batch indexing, and naturally handles retries. A 5-second lag in search reflecting a new product is acceptable.
• ✓Cart stored in Redis vs database → Redis with TTL: Cart data is ephemeral — most sessions never convert. A 30-day TTL in Redis is cost-effective and provides sub-millisecond cart reads. If Redis is lost (unlikely with replicas), the user rebuilds their cart — a minor UX inconvenience vs. the cost of storing billions of cart rows in a relational DB.
• ✓Monolith vs microservices for initial build → Microservices for catalog, inventory, orders, and payments from the start: These services have fundamentally different scaling requirements (inventory: high write contention; catalog: read-heavy; payments: strict consistency). Separating them allows independent scaling, isolated deployments, and technology choices per domain (Redis for inventory, PostgreSQL for orders, Elasticsearch for search).

• ✓Lead with the hardest problem: inventory consistency. Describe pessimistic → optimistic → Redis Lua in that order to show your reasoning, not just the answer.
• ✓The Saga pattern is expected for distributed checkout. Know the difference between choreography (event-driven) and orchestration (central coordinator). Recommend orchestration for checkout — the failure paths are more explicit.
• ✓Flash sale is a classic follow-up. The key insight is: move the reservation check out of the database and into Redis BEFORE the order is created. The DB is the long-tail persistence layer, not the gate.
• ✓Elasticsearch for search is standard, but go deeper: explain sharding strategy (30 shards for 300M docs), the CDC sync pipeline, and boosted field weights (title^3 > description).
• ✓Always mention idempotency keys for payment. External payment APIs can fail mid-request; retrying without an idempotency key double-charges the customer.
• ✓When asked about recommendations, keep it brief: collaborative filtering pre-computed nightly, top-K results cached in Redis per user, lightweight re-ranking at serve time with real-time signals.