System Design

Order Checkout

Design checkout and order placement for a store like Amazon or Instacart.

Functional requirements

• A shopper starts checkout from the cart, picks a shipping address and option, and sees the final priced order before confirming.
• Confirming places the order: inventory is reserved, the saved payment method is charged via the payment service, and an order is created; if a step fails the shopper is told and never charged for an order that does not exist.
• Inventory is held only while checkout is in progress; a hold not completed within 10 minutes is released for other shoppers.
• Shoppers can view an order's status (placed, paid, confirmed, canceled) and cancel before fulfillment starts, which refunds the charge and releases the stock.
• Once confirmed, the order goes to fulfillment and a confirmation email is sent; the warehouse must never receive the same order twice.

Non-functional requirements

• Correctness over availability for placement: no shopper is charged without an order, no order exists without a successful charge, and no SKU is oversold; refusing new checkouts during a partition is acceptable.
• Place-order is idempotent under retries: a double tap, a lost response, or a reconnecting app must never create two orders or two charges for one checkout.
• p99 under 3 seconds to confirm an order end to end, of which the payment call may take 2 seconds; checkout page loads and order status reads are under 300ms.
• Orders are durable for 7 years and an acknowledged order is never lost; every state transition is recorded so support can reconstruct any order's history.
• Shoppers can view and cancel only their own orders; checkout never touches card data and passes only a payment method token to the payment service.

Scaling & constraints

• 200 orders per second on average, peaking at 5,000 per second in the first minutes of a major sale; 30% of started checkouts are abandoned before confirmation.
• Read:write ratio is about 15:1 (order status views, order history, and checkout page loads vs. placements and cancellations).
• An order with its lines is about 3KB and averages 3 lines; each state transition adds a 300-byte event.
• The payment service answers at p50 400ms and p99 2s, and about 0.5% of calls time out with the outcome unknown; the inventory service answers a reserve or release in under 20ms p99.
• A flash sale puts up to 50,000 shoppers into checkout for one SKU with a few hundred units, within about 60 seconds.
• Orders are retained for 7 years and volume grows 30% per year; fulfillment consumes handoffs at no more than 1,000 per second and has maintenance windows of up to 1 hour.

Out of scope

• Payment processing internals: card authorization, PSP integration, and the ledger (assume a payment service with charge, refund, and status APIs).
• Fraud detection and risk scoring.
• Cart management, promotions, and tax or shipping rate calculation (assume services that return a price).
• Warehouse fulfillment, shipping, and returns after handoff.