Case Study 1: Amazon / Flipkart E-commerce

Design an online store where tens of millions of people search products, fill carts, pay and track orders, without crashing even during a flash sale.

Read every case study in the standard interview format. The 8 steps are:

1. Requirements: first ask what the system will do (functional) and how fast and available it must be (non-functional).
2. Estimation: users, QPS, storage, bandwidth. The numbers tell you how big the system must be.
3. API: which endpoints exist between client and server.
4. Data model: which tables/collections, in which database, sharded on which key.
5. High-level architecture: a diagram with users on top, then services, data and workers below.
6. Flows: the step-by-step journey of the main request.
7. Deep dives: the hardest problems and their solutions. This earns the most marks in an interview.
8. Trade-offs: what you chose and why, and what you left out.

C.1 Requirements

Functional requirements:

• Product catalog: a seller adds products; users see details, images, price and reviews.
• Search and filter: by keyword, category, brand, price range and rating; autocomplete suggestions.
• Cart: add/remove items, change quantity; the cart stays in sync across all devices after login.
• Checkout: select address, apply coupon, pay (UPI, card, COD) and confirm the order.
• Inventory: stock count per warehouse; reserve stock on order, release it back on cancel.
• Flash sale: sell limited stock (for example 10,000 phones) at a fixed time among lakhs of users.
• Order tracking: placed, packed, shipped, out for delivery, delivered statuses and notifications (SMS/email/push).

Non-functional requirements:

• Availability 99.99% for browse and search; high availability for checkout too, but correctness comes first.
• Latency: product page and search p99 < 200 ms; checkout p99 < 1 second.
• Consistency: inventory and payment strongly consistent (no overselling); catalog and reviews can be eventually consistent.
• Scale: 10 crore (100 million) DAU, normal peak 50K read QPS, flash-sale spike of 10 lakh+ (1 million+) requests/second.
• Durability: no confirmed order or payment may ever be lost (replicated DB + Kafka).

C.2 Estimation (back-of-the-envelope)

C.3 API design

C.4 Data model

C.5 High-level architecture

• Static images/JS come from the CDN (origin S3); API requests go WAF -> Load Balancer -> API Gateway (JWT + rate limit) to the microservices.
• Read path: Catalog uses Redis cache-aside, MySQL on a miss; Search runs on Elasticsearch; Cart lives in Redis with a durable copy in Cassandra.
• Checkout: Order Service checks idempotency, Inventory reserves with a 10 min TTL, and the order is saved as PENDING_PAYMENT + outbox in MySQL.
• After the gateway webhook is verified, PaymentSuccess goes on Kafka; workers send SMS/email, update ES, and release stock on timeout.

C.6 Main flows

Order placement flow (checkout):

1. The user taps "Place Order"; the app sends POST /v1/orders with a unique Idempotency-Key (UUID).
2. The API Gateway verifies the JWT, checks the rate limit and routes the request to Order Service.
3. Order Service checks the idempotency key; if an order already exists it returns the same response.
4. Order Service calls Inventory Service to reserve stock (reserved_qty += qty, 10 min TTL).
5. The order row is saved in MySQL with status PENDING_PAYMENT, with an outbox event in the same transaction.
6. The user is redirected via Payment Service to the gateway and pays by UPI/card.
7. The gateway sends a webhook; Payment Service verifies the signature and publishes PaymentSuccess to Kafka.
8. Order Service sets status CONFIRMED; Inventory converts reserved stock to sold.
9. A notification worker reads the event from Kafka and sends SMS/email/push; a fulfilment event goes to the warehouse.
10. If payment does not arrive within 10 min, the timeout worker sets the order to CANCELLED and releases the stock (compensating action).

Product search flow:

1. The user types "iphone" in the search box; the autocomplete API is called every few keystrokes (debounce).
2. The request reaches Search Service via CDN/LB; results of popular queries are cached in Redis for 1-5 min.
3. On a cache miss, Search Service builds an Elasticsearch query: text match + filters + ranking (sales, rating).
4. Elasticsearch shards search in parallel and the top results are merged.
5. Search Service enriches the product IDs with price and stock from the Catalog/Inventory cache.
6. The response carries product cards and image URLs (CDN); images load from the CDN.

Flash sale flow:

1. Before the sale the stock count is loaded into Redis (for example sale:phoneX = 10000) and pages are pre-warmed on the CDN.
2. When the sale starts, lakhs of users tap "Buy"; the API Gateway applies a per-user rate limit and bot detection.
3. Requests go into a virtual waiting room/queue so traffic reaches the backend only at a controlled rate.
4. Inventory Service does an atomic DECR through a Redis Lua script; if the result is >= 0 the user gets a token, otherwise sold out.
5. The winners' order requests go onto Kafka; Order Service consumes at its own speed and creates the orders.
6. If the user does not pay within the payment window (5-10 min), the Redis counter is INCR'd and the stock returns to the pool.

C.7 Deep dives

Problem: overselling in a flash sale (10,000 stock, 10 lakh buyers). If everyone hits a DB row lock the DB will die. So check-and-decrement is done with an atomic Lua script in Redis, and orders are then written to MySQL asynchronously via Kafka. The DB also keeps an available_qty >= 0 constraint as a safety net.

Problem: double order or double payment (retry, double click). The client sends an Idempotency-Key on every checkout; the orders table has a UNIQUE constraint. The same key is sent to the payment gateway, so retries are safe and money is not deducted twice.

Problem: distributed transaction across separate order, inventory and payment services. 2PC is slow, so use the Saga pattern. Every step has a compensating action: if payment fails, release stock and cancel the order. The outbox pattern keeps the DB write and the Kafka event consistent.

Problem: keeping the search index in sync with the catalog. CDC (Debezium) on the catalog DB sends changes to Kafka and the Search Indexer updates Elasticsearch. A lag of a few seconds is acceptable (eventual consistency).

Problem: cache stampede on a hot product. When a sale product's cache expires, thousands of requests must not hit the DB, so use request coalescing/locks, jittered TTLs, and keep hot keys in a local in-memory cache too.

Problem: payment gateway slow or down. Add a circuit breaker and keep multiple gateways; on failure, route to another gateway. For pending payments a reconciliation job polls the gateway for status.

C.8 Trade-offs

C.9 Interview tips

• Clarify scope first: not all of Amazon, focus on 2-3 core features (search, cart, checkout).
• Treat the read-heavy (browse) and write-critical (checkout) paths separately; explain caching and consistency for each.
• Always cover overselling and double payment: Redis atomic decrement, idempotency key, Saga.
• Talk with numbers: QPS, storage, cache size; this convinces the interviewer the design is grounded.
• Cover failure scenarios: payment gateway down, Kafka lag, cache failure, region outage.