Design an Order Fulfillment System

# Design an Order Fulfillment System Design the backend flow that takes an accepted customer order through inventory reservation, payment, warehouse processing, shipment, and completion. Explain state transitions, service boundaries, failure recovery, and how duplicate messages or retries are handled. ### Constraints & Assumptions - Inventory and payment are separate dependencies and cannot share one database transaction. - Events may be duplicated, delayed, or delivered out of order. - A customer must see an understandable authoritative order status. ### Clarifying Questions to Ask - When is inventory considered committed, and how long may a reservation live? - Is payment authorized before picking or captured after shipment? - Which partial-fulfillment, cancellation, and return behaviors are required? ```hint Make the state machine explicit Recovery is easier when every side effect is tied to a durable transition with a clear retry rule. ``` ### What a Strong Answer Covers - Order states and invariants across inventory, payment, and shipment. - Idempotent APIs, durable events, and workflow orchestration. - Compensation for partial failure without pretending there is a global transaction. - Reconciliation, observability, customer status, and operational controls. ### Follow-up Questions - How would you prevent overselling a scarce item? - How would split shipments change the data model?