Design an Ordering Service That Prevents the Last Item from Being Oversold

## Scenario Design the ordering portion of a food-delivery service. The system must accept an order, reserve restaurant inventory, take payment, and coordinate downstream preparation and delivery. Focus especially on the case in which only one unit remains and two users try to buy it concurrently. Compare synchronous and asynchronous steps, database locking or conditional-write strategies, and distributed coordination choices such as a saga versus two-phase commit. ### Constraints & Assumptions - Inventory must never become negative and one unit cannot be promised to two successful orders. - Requests and events can be retried or delivered more than once. - Payment authorization can succeed while a later step fails, and compensation may itself need retry. - Users need a clear pending, confirmed, or failed state rather than a false immediate success. - The source gives no traffic or latency numbers; state a baseline and identify which design choices depend on scale. ### Clarifying Questions to Ask - Is inventory maintained by the platform or confirmed by an external restaurant system? - How long may a reservation hold the last unit, and can it expire while payment is pending? - Is payment authorized before or after inventory reservation? - Which failures can be compensated, and which require human reconciliation? - Is strict availability more important than continuing orders during a regional partition? ```hint Put the invariant in one atomic boundary The last-unit decision should be a conditional update or locked transaction at the inventory authority, not a read followed by an unrelated write. ``` ### What a Strong Answer Covers - Order, item, reservation, payment-attempt, and outbox records with explicit state transitions. - An atomic inventory reservation using a conditional decrement, row lock, or serialized command per stock key. - Idempotency keys at the request boundary and stable identifiers on every asynchronous command and event. - A justified ordering of reservation and payment authorization, plus release or refund compensation. - A saga with retryable steps and durable state, and a clear explanation of why cross-service two-phase commit is usually less available and operationally heavier. - Time-bounded holds, recovery of stuck orders, reconciliation, observability, and user-visible pending states. - Partitioning and hotspot treatment for popular items without weakening the stock invariant. ### Follow-up Questions 1. What exact database statement prevents two transactions from reserving the last unit? 2. What happens when inventory succeeds, the response is lost, and the client retries? 3. How do expired holds race safely with a late payment success? 4. When, if ever, would two-phase commit be preferable to a saga here? 5. How would an external restaurant inventory system change the guarantee you can make?