Backend coding interview
Flash Sale Inventory System Coding Interview Problem
What this interview round tests
The flash sale is the canonical "prevent overselling" interview problem: limited stock, a burst of simultaneous buyers, and one non-negotiable invariant — you sell exactly what you have, never unit 101 of 100. It is a fixture of backend rounds at e-commerce and quick-commerce companies, and the follow-up question in almost every inventory-flavoured machine coding round.
Interviewers love it because the bug is invisible on a single thread. A check-then-decrement purchase flow passes every sequential test and then oversells the moment two buyers read the same stock count together. The round tests whether you can spot a time-of-check-to-time-of-use race, shrink the critical section to the contended resource, and keep the rest of the flow fast and fair.
The scenario
You are handed the purchase service of a flash-sale backend. Buyers place orders against limited per-item stock; the code checks availability, decrements stock, and records the order. Sequentially it works perfectly.
Under the test suite’s concurrent load it oversells: parallel buyers pass the same availability check and stock goes negative, failed purchases leave stock and orders inconsistent, and per-buyer purchase limits are enforced only per-thread. Your job is to make the purchase path correct under maximum contention without serialising the whole sale.
What you’ll practice
- The oversell race: why check-then-act breaks and what an atomic reserve looks like
- Making check-and-decrement a single critical section per item
- Lock granularity: per-SKU protection instead of one global lock
- Purchase integrity: a failed order leaves stock and records unchanged
- Per-buyer limits enforced correctly when one buyer races themselves
- Exact accounting: sold + remaining equals initial stock, always
How to approach it
Find the unit of contention — the per-item stock count — and make the availability check and the decrement one atomic operation on it. Two buyers must never both observe the last unit. A lock or atomic per SKU keeps the sale concurrent across items; a single global lock technically passes correctness and fails the design conversation.
Then audit everything that happens around the decrement: order records must be written only when the reservation succeeded, failures must restore nothing (because nothing was taken) or exactly what was taken, and per-buyer limits need the same atomic treatment as stock — a buyer double-clicking is just another race. The tests count sold units against initial stock down to the last item.
The starter repository ships with a failing test suite and a bundled verify.sh. Reviewed reference solutions are part of Gronex Pro — this page stays spoiler-free on purpose.
FAQ
How do you prevent overselling in a flash sale system?
Make the stock check and the stock decrement one atomic step per item, so no two buyers can act on the same observed count. In this problem you implement that directly; in production the same idea appears as conditional updates, atomic decrements, or row-level locks.
Is one big lock an acceptable answer?
It prevents overselling, but it also serialises every purchase across every item — and interviewers will ask about it. The stronger answer, and what this problem pushes you toward, is per-item protection so unrelated purchases never contend.
How is this graded?
The bundled test suite fires racing purchases at the same SKU and then audits the books: stock never negative, sold plus remaining equal to initial stock, no phantom or lost orders, and per-buyer limits honoured. It is the same standard a real flash sale is judged by.