Design a Flash Sale: Limited Stock vs a Wall of 10M Buyers

Before noon, anyone can open the product page and watch a countdown to the start. Once the sale begins, a buyer can claim one unit while supply remains, and the one-per-account rule stops resellers from scripting dozens of purchases. A claim is not yet a sale: the buyer gets a fixed window, about ten minutes, to complete payment, after which the unit returns to the pool for the next person.

The fourth requirement is easy to overlook but matters a lot to users. Everyone should learn their fate quickly and clearly, whether that is "you have one", "you are still in line" or "sold out". A spinner that never resolves pushes people to refresh, and refreshes multiply the load we are trying to control.

The system has to survive a burst on the order of 500K requests per second without any component falling over. It must never confirm more orders than there are units, which means the inventory count needs strong consistency even while everything else is relaxed for speed.

Fairness is a product promise as much as a technical goal. Buyers expect something close to first come, first served, and automated scripts should not sweep up the whole stock. Finally, the sale needs isolation from the rest of the business. If the event overwhelms shared services, ordinary customers browsing other products should still be able to add items to a cart and check out.

Assume 10 million buyers are ready when the sale opens and most of them act within roughly 20 seconds. That works out to about 500K requests per second, and impatient refreshing can push the real number higher. Against that, we have only 100K units, so about 1% of buyers can possibly succeed.

The order volume itself is modest: 100K inserts is a light job for any relational database. The difficulty is entirely in the 99% who will leave empty-handed. If each of those requests travels all the way to the database before being refused, the database dies. The estimate therefore tells us where to spend effort, which is on turning people away at the edge with as little work as possible.

Four entities model the flow: the Sale (product, start time), its Inventory count, a Reservation that holds one unit for a limited period, and the Order that a paid reservation becomes. Separating reservation from order lets the system hand out a unit instantly and settle payment later.

GET /sales/{id} returns the product details and start time. Because it is identical for everyone, it is cached at the CDN. POST /sales/{id}/reserve carries a queue_token from the waiting room and returns either a reservation_id with an expires_at time or a sold-out response. POST /orders takes the reservation ID and a payment method, creates the order and kicks off payment, returning the order ID and its status.

Static assets, the product page and the countdown are served by the CDN, so the crowd gathering before noon never reaches our origin. When the clock hits twelve, clients move into a virtual waiting room that releases people at a steady rate the backend has been sized for.

An admitted buyer calls the reserve service, which performs a single atomic decrement on a stock counter held in Redis. If the counter is already at zero, the buyer immediately hears that the item is sold out. Successful reservations are published to a Kafka topic, and the order service consumes them, writing a pending order to Postgres.

The buyer then pays through an external payment provider, and a successful charge moves the order to paid. If the window closes without payment, the order service cancels the order and increments the Redis counter, which makes that unit available to someone still waiting.

Absorbing the burst is a layered defence. The first layer is the CDN: every byte of the sale page, images and timer comes from edge servers, which remove the bulk of pre-sale load. The second layer is the waiting room. At opening time each buyer receives a position in a line, and storing a position costs almost nothing compared with processing a purchase.

The waiting room then admits buyers at a controlled pace, for example 20K per second, chosen to match what the reserve service handles without strain. Every admitted buyer gets a signed entry token, and the reserve API rejects calls that lack a valid one, so nobody can bypass the line by hitting the endpoint directly with a script.

As soon as the counter reaches zero, the waiting room broadcasts a sold-out notice to everyone still queued, which stops a flood of hopeless retries. Bot detection, the one-unit-per-account rule and a dedicated cluster for the sale complete the picture, so the regular storefront keeps its own capacity.

Locking the inventory row in the database is correct, but every buyer contends for that one lock, and the line of waiting transactions grows faster than it drains. A conditional update such as UPDATE ... SET stock = stock - 1 WHERE stock > 0 avoids an explicit lock and stays correct, yet it still funnels all writes through a single hot row.

The chosen option moves the counter into Redis and changes it with a Lua script. Redis executes scripts one after another, so the check and the decrement form one indivisible operation with no gap for a competing request. The script verifies that this user has not already claimed a unit, confirms stock is above zero, then decrements and records the user, all in memory in well under a millisecond.

Redis acts as the fast gate, but the database remains the source of truth. A unique constraint on the pair of sale and user, plus a check that confirmed orders never exceed stock, catches any inconsistency left behind if Redis fails over and loses a recent write.

A reservation holds a unit for ten minutes and turns into a sale only once payment clears. Order creation is asynchronous: Kafka soaks up the burst of 100K reservations and the order service writes them to Postgres at a rate it can sustain, so the database never sees the spike directly.

Payments must be idempotent. The order ID is passed to the provider as the idempotency key, so a network retry cannot charge a card twice, and the provider's webhook reports the final outcome. A delayed job revisits each order after ten minutes; if it is still unpaid, the job cancels it and increments the Redis counter so the next buyer in the queue gets a chance.

Because Redis, the order table and the payment records can drift after crashes or failovers, a periodic reconciliation job compares all three and corrects mismatches, for example restoring a unit whose order was cancelled but whose counter increment was lost.

The waiting room keeps the system alive, but buyers lose the feeling of instant access and must sit in a line. The Redis counter is dramatically faster than a database lock, at the cost of reconciliation jobs and a database-level guard. The payment window is a balance between buyer convenience and how quickly abandoned units return to the pool.

Running the event on a separate cluster shields the main store at the price of extra infrastructure that sits mostly idle between sales. The guiding idea across all four: soak up the surge before it reaches the core, decrement inventory atomically, and let unpaid holds expire back into stock.