Design an E-Commerce Checkout Flow That Prevents Concurrency Bugs

Design the checkout flow for a large online retailer: the path that takes a shopper's cart and turns it into a confirmed, paid order. The interviewer's emphasis was on concurrency: how your design keeps simultaneous or repeated requests from producing wrong results. ### Constraints and Clarifications - Scope: from the moment the shopper starts checkout until the order is confirmed. Browsing, search and fulfillment after the order is placed are out of scope, except where they share state with checkout, such as inventory. - Not given: traffic levels and peaks, when stock is set aside for a shopper, when the card is charged, and whether overselling is ever acceptable. Ask, or state your assumptions. ### Clarifying Questions - What are the normal and peak order rates, and are there flash sales in which many shoppers buy the same item at once? - Should stock be set aside when an item goes into the cart, when checkout starts, or only when the order is placed, and for how long? - Is the card charged when the order is placed, or authorized then and charged at shipment? - Is overselling a hard error, or can a small number of orders be cancelled or backordered afterwards? - Is one order always filled from one location's stock, or can it be split across several warehouses? ### Part 1 — The checkout flow Lay out the services, the data each one owns, the APIs, and the sequence of steps from the shopper pressing Place order to a confirmed order, including pricing, inventory and payment. Say what the system does when a step in the middle fails. ```hint Find the steps you cannot undo Mark which steps call a system outside your control, such as the payment provider, and which steps can be reversed. That tells you where the flow needs durable state between steps and what must be compensated when a later step fails. ``` #### What This Part Should Cover - The services and the data each one owns: cart, pricing, inventory, payment, order - The order of steps from cart to confirmed order, and the state recorded after each step - The client-facing APIs and their responses for success, out of stock, changed cart and declined payment - Recovery when a step fails partway, so that stock, payment and order never disagree ### Part 2 — Preventing concurrency problems Show how the design stays correct when requests race. Address the races that matter most in checkout, for example: two shoppers ordering the last unit of an item at the same moment; one shopper submitting Place order twice, by double-clicking or by retrying after a timeout; and the cart or a price changing while checkout is in progress. ```hint Name what they fight over For each race, identify the exact record that both requests try to change, then decide whether to serialize access to it or to make the change conditional on its current value. ``` ```hint A retry is a second request A client that retries after a timeout does not know whether its first request succeeded. Decide what lets the server recognize that the second request is the same order. ``` #### What This Part Should Cover - Stock updates that cannot oversell under simultaneous orders, and their behavior on a heavily contended item - Duplicate submissions and retries producing exactly one order and one charge - Detecting a cart or price that changed after checkout began - Lock scope and duration, including what is never held across the call to the payment provider ### What a Strong Answer Covers - Clarifies peak load, when stock is set aside, when payment is taken and the tolerance for overselling before designing - A flow with explicit states and compensating actions, so that every failure leaves stock, payment and order consistent - Concurrency control placed at the contended data (conditional updates, uniqueness constraints, version checks) rather than in read-then-write application logic - Idempotency end to end: from the client to the checkout service, and from the checkout service to the payment provider - Observability and reconciliation: signals for overselling, duplicate charges and stuck orders, and a process that repairs orders left in an unknown payment state ### Follow-up Questions - At the end, the interviewer hands you the code for this checkout path and asks you to review it. Which concurrency defects do you look for first? - A flash sale sends thousands of orders per second at a single item. Where does your inventory design break, and what do you change? - The payment provider times out, and you do not know whether the card was charged. What does the system do, and what does the shopper see? - An order contains items from two warehouses whose stock lives in different databases. How do you keep setting aside the stock all-or-nothing?