Design an Inventory Reservation Service

Design the service that temporarily holds stock while a shopper checks out so two shoppers can't both buy the last unit — a time-boxed reservation system under heavy contention on hot items.

Operating context. When a shopper starts checkout, the service reserves the requested quantity of each SKU against a fulfillment location for a short TTL. If the order is placed, the reservation is committed into a permanent decrement; if the shopper walks away, the reservation expires and the stock returns to available. During flash sales, thousands of shoppers race for the same few SKUs at once. The overriding rule is no overselling: the service must never let committed plus reserved quantity exceed on-hand for any SKU-location. Available-to-promise must reflect reservations in real time. Peak is about 60000 reservation operations/sec across roughly 5 million SKUs and 200 fulfillment locations.

Out of scope. Replenishment and purchasing, warehouse-management internals, demand forecasting, and the pricing/checkout UI. Assume an upstream checkout flow calls reserve, then commit or release, and a separate system feeds on-hand quantities.

What to produce. A high-level architecture covering: how per-SKU-location available-to-promise is maintained with no oversell under high contention, how reservations are decremented and committed/released atomically, how TTL expiry reclaims stock promptly, how a single hot SKU is prevented from becoming a bottleneck, and how multi-location availability is aggregated. Sketch the components and trace a reservation from reserve through commit, plus one that expires, under a burst of concurrent requests for the same SKU.