6-Million Burger Distribution

What is being asked

A flash promotion: a fixed quantity, a known start time, and tens of millions of people pressing the button in the same minute. Design a system that hands out exactly the available quantity, at most one per person, and stays up.

Requirements

Functional

• Claim one item per user, redeemable at a store.
• Stop exactly when stock runs out.

Non-functional

• A huge spike at a known time.
• No overselling; no double claims.
• Fair enough that users do not feel cheated, and resistant to bots.

Design

1. Stock is split in advance across shards of a fast in-memory store, for example by region.
2. A claim request first runs an atomic "decrement if greater than zero, and add this user to the claimed set" on its shard. This takes microseconds and rejects most requests immediately once stock is gone.
3. A successful claim is placed on a queue. Workers write the durable record, with a unique constraint on the user, and issue the voucher.
4. The app shows "you got one" as soon as the atomic step succeeds, and "sold out" otherwise.

Key decisions and trade-offs

• Keep the database out of the hot path. A relational database cannot take a million conditional updates a second on a few rows. Decide in memory, persist asynchronously.
• Pre-sharded stock removes the single hot counter. A shard that sells out early can borrow from another, or simply report sold out.
• Shed load early. Static pages from a CDN, rate limits at the edge and a cheap rejection path keep the expensive path for the few who succeed.
• Durability gap. If the in-memory store fails between the decrement and the queue write, claims can be lost; replicate it and reconcile counters with the queue.

Follow-up questions

• How do you stop one person claiming with twenty accounts?
• How would you make the outcome fair when everyone arrives in the same second?
• What happens to items claimed but never redeemed?
• How do you rehearse for a spike you cannot reproduce in production?