Flash Sale

Three tiers isolated by concern: queue tier (absorb + order the herd), checkout tier (atomic purchase), payment tier (pre-auth + capture). A CDN serves the static product page; only the queue-enter and purchase calls hit the backend.

The single hardest problem: 100K users all call POST /purchase in 1 second. If each checks inventory, sees "999 remaining," and then decrements — you sell 100K items instead of 1K. Classic lost-update / check-then-act race.

Solution: Redis Lua atomic decrement.

-- Redis Lua script: atomic decrement-if-positive
local stock = redis.call('GET', KEYS[1])
if tonumber(stock) > 0 then
  redis.call('DECR', KEYS[1])
  return 1  -- success
else
  return 0  -- sold out
end

This runs atomically inside Redis (single-threaded). No race. No oversell. Each call either gets a unit or doesn't. The caller gets a definitive answer in < 1 ms.

Waiting room. Without it, 100K users slam the checkout tier simultaneously — even if inventory check is atomic, the backend can't handle 100K DB writes/sec. Solution: a queue that controls admission rate.

1. User enters queue. Redis ZADD with score = enqueue timestamp. Returns ticket (signed JWT) + position.
2. Admission controller (a cron or timer) pops the top N users per second (e.g., 500/sec) from the sorted set. Marks them "admitted" in Redis.
3. Admitted user's next poll returns status=admitted. Client-side JS transitions to checkout page.
4. User calls POST /purchase with ticket. Checkout service verifies ticket is admitted, calls Redis Lua decrement, on success writes order to Postgres + captures pre-authed payment.
5. When inventory hits 0, admission controller stops admitting. Kafka event fires. SSE/WS pushes "sold out" to all remaining queue connections.

Pre-authorization. While user is in queue, client silently calls POST /pre-auth with their saved card. If they win a slot, capture is instant — no "enter your card" delay at checkout. If they lose, auth auto-voids after 30 min. UX: "You're in line. We'll charge your card only if you get one."

• Redis atomic vs Postgres FOR UPDATE. Redis Lua: ~50K ops/sec on single key, sub-ms. Postgres pessimistic lock: ~5K/sec, 2–5 ms. Redis wins overwhelmingly for the hot path. Postgres is the authoritative ledger written after Redis succeeds.
• Waiting room (fair, controlled) vs first-come-first-served (unfair, chaotic). Without a queue, users with lower latency (closer server, faster network) win. Queue equalizes: everyone gets a ticket; admission is FIFO. Supreme and Nike SNKRS both adopted queues for this reason.
• Per-item vs per-SKU inventory. Flash sales typically have one SKU. Single Redis key works. Multi-SKU (sizes, colors) needs one key per variant — same Lua pattern, multiple keys.
• Optimistic (check-and-set) vs pessimistic (lock). At 100K contenders, optimistic = 99K retries. Pessimistic = sequential. Redis Lua is effectively "pessimistic within a single thread" — no retries, no contention, because there's only one thread.
• Pre-auth cost. Pre-authorizing 100K cards when only 1K win = 99K void auths. Payment processors charge ~$0.01 per auth. 100K × $0.01 = $1K per sale — acceptable for high-value items; questionable for $5 items.

1. Lead with the waiting room. "100K users → 500/sec admission rate → smooth backend load." This is the insight that separates good from great.
2. Redis Lua for atomic inventory. Name it explicitly — "single Redis key, Lua DECR-if-positive, no race." Shows you've actually built these systems.
3. Pre-auth payment in queue. This UX detail (checkout = one click, not "enter card") is the kind of production nuance interviewers love.
4. Bot mitigation is load-bearing. Without it, bots take all 1K items. CAPTCHA + proof-of-work + device fingerprinting. Don't skip this.
5. Distinguish from Ticketmaster. Ticketmaster = seat selection + hold pattern. Flash sale = single SKU + atomic counter. Simpler inventory model, harder contention model.