Database Concurrency & Scaling interview question · Most asked
How do you prevent overselling in a flash sale with 50,000 buyers in the first minute?
Summary
One short transaction per attempt with an atomic conditional decrement and an idempotency key; payment outside the transaction; expiring holds returned by a sweeper; spread or meter the hot inventory rows (buckets or an admission queue); and isolate the endpoint's pool.
Longer Answer
Never hold locks during payment calls. Use a constraint (stock >= 0) as the final guard, load-test with concurrent requests on the same SKUs, and monitor invariants (held + paid ≤ initial stock) live.
Key Points
- Atomic decrement + idempotency key
- Reserve → pay → confirm
- Expiring holds
- Spread/meter hot rows
Deep dive: Capstone: Never Oversell
More most-asked Database Concurrency & Scaling questions
- An order is saved but the 'OrderPlaced' event sometimes never reaches Kafka. How do you fix it?
- After a deploy, logs show hundreds of 'deadlock detected' errors per hour on checkout. Walk through how you'd investigate.
- Two customers buy the last item at the same moment and both orders are confirmed. What happened, and how do you prevent it?
- Your service throws 'connection pool exhausted' errors but database CPU is only 20%. What's going on?
- Why shouldn't you call a payment API inside a database transaction?
- What's the difference between Read Committed and Repeatable Read in practice?
- Database CPU is at 85%. How do you decide what to optimise before buying a bigger server?
- A user saves their profile and the next page shows the old data. Reads go to replicas. How do you fix it?