Machine coding round
Inventory Stock Reservation Coding Interview Problem
What this interview round tests
The reservation model is the idea that separates real inventory systems from toy ones: stock is not one number but three — on hand, reserved, and available — and an order does not decrement stock, it reserves it, to be committed on dispatch or released on cancel. This problem implements that model against warehouses, and it is the backbone of e-commerce and quick-commerce machine coding rounds.
Interviewers use it because the naive design fails on the first follow-up question. Decrement stock at order time and you cannot answer: what happens when payment fails? When the order cancels? When two orders want the last unit? The reservation model answers all three — and brings its own bookkeeping obligations: a multi-line order must reserve everything or nothing, duplicate lines for the same SKU must merge rather than double-reserve, and every reservation must eventually resolve to confirmed or released, with the three quantities reconciling throughout.
The scenario
You are handed the inventory service of a commerce backend: orders reserve stock from warehouses, reservations are confirmed on fulfilment or released on cancellation, and availability queries drive what customers can buy. All the operations exist, and the test suite shows the accounting is broken.
Available stock ignores reservations so the same units sell twice, an order with two lines for the same SKU reserves double, a multi-line order that fails partway keeps the lines it already grabbed, cancelling returns wrong quantities, and confirming ships stock that was never reserved. Your job is to make the three-quantity model hold through every transition.
What you’ll practice
- The three-quantity model: on hand = reserved + available, at every moment
- Reservation lifecycle: reserve → confirm (ship) or release (cancel)
- Duplicate line merging: two lines for one SKU become one reservation
- All-or-nothing multi-line reservation with rollback on partial failure
- Availability queries that subtract live reservations, not just sales
- Idempotent cancel and confirm: repeating a transition has no extra effect
How to approach it
Make the invariant executable first: on hand equals reserved plus available for every SKU in every warehouse, checkable after any operation. Then define each operation as a movement between those buckets — reserve moves available to reserved, confirm moves reserved out of on hand, release moves reserved back to available — and refuse any operation that would drive a bucket negative.
Handle the order as a unit: normalise its lines first (merge duplicates by SKU), validate the whole set against availability, and only then apply — so a failure on the third line means the first two were never taken, or are precisely undone. Cancel and confirm then become bounded transitions on a known reservation, and making them idempotent — a double cancel releases once — closes the retry cases the tests finish with.
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
Why reserve stock instead of just decrementing it?
Because an order can still fail after placement — payment declines, the customer cancels, fulfilment substitutes. A decrement has no memory, so undoing it safely is guesswork. A reservation is an explicit claim with a lifecycle: confirm it when goods ship, release it when the order dies, and the books stay explainable throughout.
What is the duplicate line-merging requirement about?
Real carts contain the same SKU twice — added from two pages, or by a retried request. Reserving each line independently double-claims stock and can reject an order the warehouse could actually fulfil. Normalising lines per SKU before validating is a small step that the tests, and real order systems, both require.
How does this relate to the flash sale problem?
They are the two halves of inventory correctness. This problem is the accounting model — reserved versus available, rollback, lifecycle. The flash sale is the same last-unit question under maximum concurrency. Solve this one first; its model is what makes the concurrent version tractable.