Design an Inventory Service with Reservations, Hot SKUs and Oversell Prevention

Design an inventory management service for an online ordering platform. The service tracks how much stock of each product (SKU) is available, reserves stock while a customer's order is being placed, and then either commits the reservation when the order is fulfilled or releases it when the order is cancelled or abandoned. Orders usually contain several SKUs. The discussion is expected to go deep on: - **Concurrency**: many orders updating the same stock at the same time. - **Hot SKUs**: a few products that receive a large share of the traffic. - **Reservations**: holding stock for an order between checkout and fulfillment. - **Overselling**: never promising more units than exist. - **Partial fulfillment**: what happens when only part of an order can be satisfied. ```hint Model the states of a unit Before choosing storage, write down which states a unit of stock can be in and which events move it between them; most of the concurrency discussion follows from that. ``` ```hint One SKU, many buyers Think about what serializes updates when many checkouts target the same SKU at the same moment, and whether that serialization point can be split or moved. ``` ### Clarifying Questions - Is stock tracked per location (store or warehouse) as well as per SKU, and how is the location for an order chosen? - Where do stock changes come from: deliveries, stock counts, external systems? How closely does the recorded count match the shelf? - How long may a reservation hold stock before it expires? - When only part of an order is available, what should happen: fulfill what is available, offer substitutes, split the order, or fail it? - What scale should the design handle: number of SKUs and locations, peak order rate, and the peak rate for the single hottest SKU? - Is slightly stale availability acceptable on browsing pages, as long as checkout is exact? ### What a Strong Answer Covers - A stock model that separates on-hand, reserved and available quantities, and reservation records with an explicit lifecycle and expiry. - A concurrency mechanism that makes overselling impossible for recorded stock, with a justification over the alternatives. - Specific strategies for hot SKUs and an explanation of the throughput limit they work around. - Idempotent reserve, confirm and release APIs, and how the service fits into the order and payment flow. - Partial fulfillment both at reservation time and when a shortage is discovered during fulfillment. - Separation of the exact checkout path from the cached availability path, plus failure handling, reconciliation and observability. ### Follow-up Questions - A flash sale sends far more demand to one SKU than there is stock. How does the design protect both the database and the user experience? - A stock count shows fewer units than are already reserved for confirmed orders. What happens? - How would you run this service across several regions, and where does the source of truth for one location's stock live? - How do you make sure a retried reserve call from the order service never reserves stock twice?