Keep the stock counter in one atomic place and decrement it atomically — a Redis DECR (or a Lua script) that returns the remaining value. If the result is < 0, that request lost; the database is never the concurrency gate. Everything else is about shedding the other 999,000 requests cheaply.
1M clients ─▶ CDN/edge (waiting room, drop bots) ─▶ LB
│
Stateless API pods
│
Redis: DECR stock (Lua: check+dec+record)
│hit>=0 │miss<0
▼ ▼
enqueue order ─▶ DB reject "sold out"
DECR stock:sale123 is atomic — no two requests can both read "1 left". A Lua script does it in one round trip: check remaining, decrement, and record SADD winners:{sale} {user} so one user can't win twice. Lua runs single-threaded on Redis, so the whole check-and-set is one atomic step.>= 0) are pushed to a queue; a worker writes the order to Postgres asynchronously. The DB never sees 1M concurrent writes — only ~1000 winner writes.The interviewer wants to see you name the race condition precisely: SELECT stock then UPDATE in two statements lets two requests both read 1000 and both sell — classic oversell. "Good" is "use a transaction / SELECT ... FOR UPDATE"; "great" is recognizing that row locks serialize 1M requests onto one hot row and collapse throughput, so you move the contention to a single-threaded atomic op in Redis and only persist winners. The trap is trusting application-level checks (if (stock > 0)) without atomicity.
FOR UPDATE: Redis handles 100k+ ops/s on one hot key; a Postgres row lock serializes and melts under a flash sale. Reserve the DB for durable order records.A library of IT interview questions with detailed answers — from Junior to Senior.
Donate