Design a Grocery-Ordering Backend with Reliable Inventory Reservations

Design the backend of a simplified grocery-ordering service, focusing on inventory. Explain how products and store-level stock are represented, how orders reserve items, and how the system handles concurrent purchases and failures. Frontend design is out of scope. ### Constraints Store count, catalog size, traffic, inventory accuracy, and substitution policy are unspecified. Clarify the desired guarantees before choosing an architecture. Any specific reservation, payment, or fulfillment policy in your design must be labeled as an assumption. ### Clarifying Questions - Is inventory authoritative in this service or synchronized from store systems? - When should stock be reserved, decremented, released, or reconciled? - Can an order be partially fulfilled, and how are substitutions handled? - What happens when payment or fulfillment fails after inventory has been reserved? ```hint Separate stock from availability Physical stock, reserved quantity, and quantity available for a new order may be different values. ``` ### What a Strong Answer Covers - Store-product identity, inventory state, and ordering APIs. - Concurrency control, reservations, idempotent transitions, and recovery. - Reconciliation with physical inventory and explicit treatment of uncertainty. ### Follow-up Questions - How would you handle a reservation that expires just as checkout completes? - How would you avoid overselling a popular item during a burst of orders?