Code an Online Shopping System with Order States, Inventory and Payment, Then Scale It

In a technical phone screen you are asked to write the code for an online shopping system that covers placing orders, inventory, payment, and the transitions of an order between its states. For the rest of the interview the same problem becomes a system design question: if this were a design round, how would you build it as a production service? The report gives only this scope, so the order states, the rules for reserving stock and taking payment, and the expected scale are open: settle them with the interviewer. ### Clarifying Questions - Which order states are required, and which transitions between them are legal? For example, can a paid order still be cancelled, and can a shipped one? - Is stock reserved when the order is placed, or only deducted once payment succeeds? If it is reserved, how long may an unpaid order hold it? - Is payment a call to an external provider that can decline, time out, or report its result later? May a customer retry a failed payment on the same order? - Can one order contain several products with different quantities, and must the whole order succeed or fail together? - Must the code stay correct when several customers buy the same product at the same moment? ### Part 1 — Implement the core system Write the classes for products and stock, orders with their line items, and payment, plus a service that places an order, takes payment, and moves the order through its states. An illegal transition, such as shipping an order that has not been paid, must be rejected, and the same unit of stock must never be sold twice. ```hint One place for the rules Ask which single piece of code should answer "may an order in this state move to that state?", so that no method can change a status without that check. ``` ```hint The last unit Walk through two customers buying the last unit at the same moment, and a payment that is declined after stock has been set aside for the order. ``` #### What This Part Should Cover - Clear entities and responsibilities: catalog, inventory, orders and line items, payments, and an orchestrating service - An explicit order state machine that rejects illegal transitions - Stock that is reserved and released correctly, with no overselling under concurrent orders - Behaviour when a payment is declined, times out or is retried, and tests for these paths ### Part 2 — Design it as a production service Now treat the same problem as a system design question. Describe the services, data stores and APIs; how an order, its stock and its payment stay consistent when they are owned by different services and the payment provider is an external system; and how the design scales. ```hint Where the transaction ends List the steps of a purchase and mark which ones can no longer share a single database transaction once inventory, orders and payments are separate services. ``` ```hint Lost responses Think about a payment request whose response never arrives, followed by a retry of the same request. ``` #### Clarifying Questions for this Part - What order volume is expected on average and at peak, and how many products are there? - Which interactions does the payment provider offer: a synchronous charge, a later notification of the result, a way to look up a payment? - Is stock held in one warehouse or in several? #### What This Part Should Cover - Service boundaries, data ownership, data model and APIs for orders, inventory and payments - Cross-service consistency for reserve, pay, confirm and compensate, with idempotent operations and reliable events - Concurrency control on stock and scaling of reads and writes, including very popular products - Failure handling and monitoring for stuck or inconsistent orders ### What a Strong Answer Covers - States, reservation timing and payment rules agreed before coding - Small, readable, testable code with the state machine enforced in one place - No overselling and no double charging, under concurrency and under retries - Edge cases such as unknown products, non-positive quantities, cancelling after shipping and duplicate payment results - A clear path from the in-process design to separate services, with the trade-offs of each consistency choice explained ### Follow-up Questions - A flash sale sends many more buyers than there are units to a single product. How do you prevent overselling without overloading the stock database? - The payment provider confirms a payment after the order's reservation has expired and its stock has gone to another customer. What does the system do? - How would you add a new state, such as a partial shipment, without breaking orders already in flight? - How would you find and repair orders that are stuck waiting for a payment result?