Design flash-sale checkout

At exactly 12:00, 10,000 limited-edition sneakers go on sale and 200,000 people press "Buy" within two seconds. For the rest of the day the shop is quiet. The design has to survive a crowd twenty times larger than the stock, sell every pair exactly once, keep bots from buying everything, and keep the rest of the shop working while it happens. This page has material for a full 60–90 minute interview.

1. The prompt

"An online shop runs flash sales: a limited quantity of a product at a special price, starting at a set time. Design the checkout so it works when far more people show up than there is stock."

Design D15 (ticket booking) covered races on individual seats and a waiting room. A flash sale differs in three ways:

• One counter: identical units share a single stock counter, which becomes the hottest row in the company.
• The crowd: it all arrives in one second, not over minutes.
• The rest of the shop: it must keep serving its normal traffic at the same time.

2. Frame the problem

3. What it must do

1. A buyer can try to secure one unit when the sale opens, and is told quickly whether they got one.
2. A buyer who secured a unit can pay within the hold time; then the order is confirmed.
3. Everyone sees the sale's state: countdown, open, their place in line, sold out.

Not now:

• Raffles (enter, then winners are drawn): a different, easier design. Mention it as a fairness alternative.
• Dynamic pricing: a separate product decision.
• Shipping and fulfilment: ordinary order processing after the sale.
• Resale prevention: a policy problem, not a checkout one.

4. How well it must do it

5. Numbers that change the design

Skip product-page traffic numbers: the page is static and served by the CDN. Saying so is enough.

6. The nouns

• Sale: product, start time, per-customer limit, status.
• Stock: what's left, per size.
• Hold: a reservation of one unit for one buyer, with an expiry.
• Order.
• Payment.
• Waitlist entry.

sales     sale_id, sku, starts_at, limit_per_user, status (scheduled | open | sold_out | closed)
units     sale_id, size, unit_no, status (free | held | sold), hold_id         (one row per unit, see 9.1)
holds     hold_id, sale_id, user_id, unit, expires_at, status (active | paid | expired)
          UNIQUE (sale_id, user_id)                                          (one per customer, enforced by the database)
orders    order_id, hold_id, user_id, amount, payment_id, status

7. The contract

REST, with the user from the session token. The "buy" call is deliberately small: it only secures a hold; payment is a separate call.

GET  /v1/sales/{sale_id}               → {status, starts_at, server_time, sizes: [{size, available: true|false}]}   (cached at the CDN for 1 s)
POST /v1/sales/{sale_id}/holds         {size}   Idempotency-Key: …     (needs an admission token from the waiting room)
     → 201 {hold_id, expires_at} | 409 {status: "sold_out", waitlist: true} | 429 {retry_after}
POST /v1/holds/{hold_id}/pay           {payment_token}   Idempotency-Key: …   → {order_id, status: "confirmed"}
DELETE /v1/holds/{hold_id}             → release early
POST /v1/sales/{sale_id}/waitlist      {size}   → join the queue for released units

server_time lets the countdown use the server's clock, not the phone's, so nobody's button unlocks early. "Available" is a yes/no flag, not an exact count, which keeps the response cacheable.

8. First working version

One app tier, one relational database, the payment provider, and a CDN for the product page.

8.1 Securing a unit

One transaction: decrement the size's stock row only if it's above zero, and insert the hold. The unique key on (sale_id, user_id) enforces "one per customer" even if someone sends ten requests at once.

BEGIN;
UPDATE stock SET available = available - 1 WHERE sale_id = $1 AND size = $2 AND available > 0;   -- 0 rows → sold out
INSERT INTO holds (hold_id, sale_id, user_id, size, expires_at) VALUES (…, now() + interval '10 minutes');
COMMIT;

8.2 Paying

The buyer pays through the payment provider with an idempotency key (Design D16). On success, one transaction marks the hold paid and creates the order. A sweeper job returns expired holds to stock every few seconds.

8.3 Showing the sale's state

The product page is static HTML on the CDN. A small status endpoint (open, sold out per size) is cached for one second, so 200,000 people polling it cost the origin about one request a second.

9. Make it hold up

9.1 The hot stock counter never oversell · fast answer

Whichever counter you choose, publish a sold-out flag per size the moment stock hits zero, and cache it at the edge. From then on, every other buyer gets "sold out" from the CDN in milliseconds, without touching the counter. Splitting stock into several sub-counters (say 10 buckets of 1,000) is another way to spread the load; the catch is a bucket that empties early while others still have stock, so a miss must try another bucket.

9.2 Reserve first, pay second never oversell · sell it all

• Order matters: take the unit before payment. If payment comes first, everyone who saw "available" in the first seconds pays, and thousands of payments must then be refunded. The lab shows the size of that mistake.
• Holds expire: each hold carries expires_at. The buy query can treat expired holds as free, so correctness doesn't depend on the sweeper (the same trick as Design D15). The sweeper tidies rows and triggers the waitlist.
• The waitlist gets released units: when a hold expires or a payment fails, the unit goes to the next person on the waitlist, who gets a short hold of their own and a notification. Without this, units come back after the crowd has left and stay unsold.
• Payments are idempotent: the hold id is the idempotency key's root, so a retried payment never charges twice (Design D16).

9.3 Absorbing the crowd at the edge fast answer · isolated

Also prepare for 12:00: pre-warm caches and connection pools, pre-scale the hold service, and make the static page and assets cacheable so the moment the button unlocks costs the origin nothing. The countdown uses server_time, so a phone with a fast clock can't jump the queue.

9.4 Bots and fairness fair

• One per customer, enforced by the database: the unique key on (sale_id, user_id) holds no matter how many requests or tabs a person opens.
• Make accounts expensive: require accounts created before the sale was announced, verified payment methods or phone numbers, and a purchase history for very hot drops.
• Challenge at the door, not at the counter: bot checks (device signals, behavioural checks, a challenge for suspicious sessions) run while people wait in the waiting room, so they don't slow the hold step.
• Randomise the start: everyone in the room at 12:00 gets a random position, so speed alone doesn't win.
• Bind tokens to sessions: admission tokens are signed, expire quickly and are tied to the session and device, so they can't be shared or sold.
• Post-sale checks: cancel orders that share shipping addresses or cards across many accounts before they ship.

9.5 Keeping the rest of the shop alive isolated

• Bulkheads: the sale runs on its own hold service, its own database (or at least its own connection pool) and its own queues, so its load can't starve everyday checkout (Module 24).
• Turn things off: during the sale, disable expensive extras on the product page (recommendations, live review counts) with feature flags.
• Watch your partners' limits: payment providers and fraud-check services have rate limits too. Since payments are spread over the 10-minute hold window, keep a client-side limiter in front of them.
• Kill switch: a single flag pauses the sale (for a price mistake or an attack) and shows a holding page from the CDN.

9.6 Orders and payments after the rush sell it all · never oversell

Once a hold is paid, the rest is ordinary order processing, but there is a lot of it in a short time. The payment confirmation writes the order and an outbox event in one transaction (Module 22). Workers take it from there: confirmation email, warehouse allocation, invoicing. Each step is idempotent and retryable. A reconciliation job after the sale checks that units sold = paid orders = payment provider captures, and refunds anything that doesn't match.

9.7 The whole design after the deep dives

One buyer, from the countdown to a confirmed order, through every part.

10. Interviewer follow-ups

11. When things break

12. Wrap-up and the clock

Trade-offs we made:

• A waiting room (slower for some, fair for all) instead of a free-for-all.
• Unit rows with SKIP LOCKED in the transactional store, rather than a faster but separate counter.
• Reserve before payment, at the cost of handling expiries.
• A yes/no availability flag instead of exact live counts.
• Bulkheads, at the cost of extra infrastructure.

What we'd watch:

• Hold latency and error rate.
• Admission rate against hold capacity.
• Units held, paid and expired.
• Waitlist conversions.
• Origin requests per second.
• Everyday checkout latency (the bulkhead check).
• Payment errors.

At 10×:

• More edge capacity.
• Raffles for the hottest drops.
• Per-location stock.
• Stricter account rules.

Common mistakes:

• Charging before reserving.
• A single stock row with no plan for contention.
• Letting 200,000 requests reach the database to learn "sold out".
• Holds that expire into nowhere.
• Trusting the client's clock.
• Forgetting the rest of the shop.
• "We'll autoscale".

13. Try it, check yourself, read more

Sale simulator. 10,000 units; 200,000 buyers arrive in the first two seconds. Payments take 3–8 s and 15% are abandoned. Buyers who wait more than 5 s for an answer give up. Once a size sells out, a cached flag answers everyone else instantly, and abandoned units go to the waitlist.

Illustrative rates: one locked row ~500 changes a second; unit rows with SKIP LOCKED ~20,000; a Redis counter ~50,000. Real numbers depend on hardware and transaction size.