Design a Flash Sales Platform

Problem statement

Design a flash sales platform that runs limited-time and limited-inventory sales where demand exceeds supply by two or three orders of magnitude. A typical headline event places 5,000 units on sale at an announced start time while 2 million people refresh the page in the same second. The platform must schedule sale windows, admit buyers fairly, show live availability, convert winners into paid orders, and never sell more units than exist.

This is not a scaled-up normal e-commerce storefront. Ordinary retail traffic is distributed across millions of SKUs and reads dominate. A flash sale inverts both properties: traffic concentrates on one SKU and one counter for a few minutes, and the write path is the product. The sale is effectively a massively multiplayer race for a shrinking integer.

Why the problem is distinctive

Three facts separate flash sales from every other e-commerce workload. First, the demand-to-supply ratio is extreme: 2,000,000 participants competing for 5,000 units means 99.75% of buyers must lose, and the system must tell them so quickly, honestly, and without wasting backend capacity on them after stock is gone. Second, load arrives as a thundering herd: the countdown clock synchronizes millions of clients to hit the same endpoint within a one-second window, producing a spike 100x to 1,000x the steady-state rate. Third, the critical resource is a single logical counter. Every purchase attempt must serialize against inventory for that SKU, which makes naive horizontal scaling impossible at exactly the layer that matters.

An oversell is not a retryable bug. If the platform sells 5,007 units of a 5,000-unit item, seven customers must be cancelled on after receiving a win, which becomes a support, chargeback, and reputational incident. Conversely, an undersell caused by overly conservative failure handling leaves revenue and inventory stranded. The consistency target is therefore exact, not eventual.

Public operating baseline versus design assumptions

Public evidence shows the category operates at extreme scale. Alibaba reported a peak of 583,000 orders per second during its 2021 11.11 shopping festival, and its 2019 peak was 544,000 orders per second. Ticketmaster disclosed that its November 2022 artist presale day processed roughly 3.5 billion total system requests while selling 1.5 million tickets in the first hour, with bot traffic reported at many times normal levels. Shopify reported more than 11.5 billion dollars of gross merchandise volume across the 2023 Black Friday through Cyber Monday weekend, with checkout bursts concentrated in minutes. These are company-reported figures and serve as scale context, not as requirements for this design.

For capacity planning, this answer explicitly assumes a marketplace running 50 flash sales per day, where the headline sale has 5,000 units, 2 million concurrent participants at start, a 400,000 requests-per-second peak in the first 30 seconds, and 30,000 purchase attempts per second decaying over ten minutes. Unless tied to a citation, every number in this answer is a stated design assumption, target, or budget.

The four architectural planes

1. Edge admission plane: CDN-served static pages, rate limiting, bot challenge, and countdown synchronization. Its job is to absorb 90%+ of requests before they reach origin.
2. Fairness plane: virtual waiting room or lottery that converts a simultaneous mob into a paced, bounded stream of eligible buyers.
3. Inventory authority plane: the single-writer-per-shard counter service that is the only component allowed to decrement stock, with atomic, idempotent reservations.
4. Order completion plane: reservation-to-payment saga, TTL-based stock release, order ledger, notifications, and reconciliation.

A strong answer keeps these planes separate. The edge may shed load without touching inventory. The fairness plane may degrade to approximate positions without weakening the oversell invariant. The order plane may lag in notifications while the counter remains exact.