Flipkart System Design: Big Billion Days Flash Sales

Start by splitting the system along the read/write seam, because that split drives every other decision. The read path serves browse, search, and product detail pages; it is enormous in volume but tolerant of staleness, so it leans on a CDN, multiple cache layers, and a search index. The write path serves cart, inventory reservation, checkout, and order management; it is smaller in volume but unforgiving, it must be strongly consistent and idempotent. On the read path, a request from a browser or app first hits a CDN edge (static assets, images, and cacheable PDP fragments). Dynamic requests pass through an API gateway / load balancer into stateless service tiers. Catalog reads are served from a product service backed by a fast key-value store (Flipkart famously runs Aerospike here, serving the search bar, pricing, recommendations, ads, and inventory reads at ~90M QPS aggregate with sub-millisecond latency). Search and faceted filtering hit a dedicated inverted-index cluster (Elasticsearch/Solr-class), kept in sync from the catalog via a change stream. The source of truth for product data lives in a durable store and is denormalized into these read-optimized projections, classic CQRS. On the write path, adding to cart writes to a cart service (a low-latency KV store keyed by user). Checkout is where the interesting consistency work happens: the system reserves inventory against a strongly-consistent inventory ledger (an atomic decrement with a reservation TTL), creates an order in a "pending" state, then drives the order through a distributed workflow, payment authorization, inventory commit, packing, shipping, using a saga / state machine. Flipkart open-sourced exactly this: Flux, a state-machine orchestration framework that models order fulfillment as states (Order Created, Confirmed, Packed, Shipped) with event-driven transitions, retries, and replay. Each step is idempotent (keyed by an idempotency key derived from the order/saga id), and failed steps trigger compensating actions rather than a single big ACID transaction across services. For Big Billion Days, the architecture adds shock absorbers in front of the write path. Because traffic runs 5-10x normal and flash sales concentrate millions of users on a single SKU, you put a virtual waiting room / admission control in front of checkout, rate-limit per user and per SKU, and front the hot inventory key with an in-memory counter and a queue so the database sees a smooth, bounded write rate instead of a spike. Flipkart runs all of this on its own Flipkart Cloud Platform (FCP) over Kubernetes, bursting overflow workloads to GCP during peaks, with chaos testing and autoscaling so individual microservices scale independently based on demand. In a real interview, sketch this on the whiteboard before diving into any single box.

In a real interview, sketch this on the whiteboard before diving into any single box.