Design an Inventory Service with Stock Reservations That Prevents Overselling

Design an inventory service for a store that sells items in limited stock. When customers place orders, the service must reserve stock for them so that the same unit is never promised to two orders. The discussion centered on three topics: how inventory is reserved, how concurrent requests are handled, and how overselling is prevented. ```hint Promised is not sold Separate the units physically on hand from the units promised to orders that have not completed, and decide what happens to a promise that is never fulfilled. ``` ```hint Two buyers, one unit Walk through two requests that both see one unit left at the same moment, and decide exactly where in your design that race is settled. ``` ### Constraints and Clarifications - Not given: the number of items and locations, order rates, how long a reservation should hold, and where the authoritative stock count comes from. Ask, or state your assumptions. ### Clarifying Questions - Is stock tracked per item overall, or per item at each location such as a warehouse or store? - When is stock reserved (when an item is added to a cart, at checkout, or at payment), and how long does a reservation hold? - Is overselling ever acceptable with a later substitution or refund, or must the system prevent it strictly? - What are the peak order rates, and are there hot items for which many buyers compete for a few units? - Where do stock counts come from, and how often are they corrected by deliveries or physical counts? ### What a Strong Answer Covers - Settles reservation timing, hold duration and how strictly overselling is prevented before designing - A data model that separates on-hand, reserved and available stock, with reservation records that carry a state and an expiry - An atomic reserve operation and an argument for why it cannot oversell under concurrent requests - The reservation lifecycle: confirmation, release, expiry, idempotent retries and orders with several items - Scaling for hot items, reconciliation with physical counts, and the metrics that reveal oversells and leaked holds ### Follow-up Questions - Thousands of buyers try to reserve the last few hundred units of one item within seconds. How does your reserve path hold up, and what would you change? - The payment call times out after the reservation succeeded. How do you avoid both a leaked hold and a double charge? - A physical count finds fewer units than the system shows, and some of them are already reserved. What happens to the open reservations? - An order has several items and one of them cannot be reserved. How do you avoid holding the others longer than necessary?