Design a Flash-Sale System

Design the backend for a flash-sale system: a scheduled event where a fixed, small quantity of high-demand inventory (think a limited sneaker drop or a concert on-sale) is released at a precise second and sells out in seconds under a stampede of buyers.

The crux is not throughput for its own sake — it is correctness under extreme contention on a tiny pool of stock. Ten thousand buyers may race for two hundred units in the first two seconds. You must never oversell, must decide winners fairly, and must keep the rest of the storefront alive while the sale melts the checkout path.

Operating context. A single sale offers 200–5,000 units of one SKU. At the drop instant, 50,000–500,000 clients hit the reserve endpoint within the first 3 seconds, i.e. bursts of 100,000+ reserve attempts/sec against inventory that can satisfy well under 1% of them. The floor is heavily write-contended (every attempt targets the same stock counter) yet almost entirely doomed to fail. Reservations that are granted must be paid within a hold window (e.g. 5 minutes) or the unit returns to the pool. Bots and scripts will attempt to grab disproportionate stock.

Out of scope. Payment-gateway internals (assume a charge API exists), catalog/browse pages, post-purchase fulfillment and shipping, recommendation and search, and the CAPTCHA vendor's own implementation. Assume separate teams own those.

What to produce. A high-level architecture covering: the reserve → hold → confirm request flow; admission control at the edge (how you shed or queue the stampede before it reaches inventory); the atomic-decrement design that guarantees no oversell on the single hot counter, and how you spread that write hotspot; the hold/expiry lifecycle and how expired holds are reclaimed; fairness and anti-bot controls (queueing, per-identity limits, waiting-room tokens); and graceful degradation of the wider storefront while the sale is hot. Sketch the major components and the request flow; we will probe specifics at checkpoints.