Amazon Checkout

The problem

"Design the checkout of a big online shop like Amazon." A shopper fills a cart over days, on a phone and a laptop, then presses Place order. The items may sit in different warehouses, the card should be charged only when the goods ship, and the order can be canceled until it leaves.

This practice problem reuses the pattern of Design a Flash Sale, every day. Four things are new: the cart itself, several items from several warehouses, the hold and the charge, and the order's states. Park returns and suggestions.

The numbers

From the interviewer: about 10 million orders a day, and about 50 cart reads and changes per order placed, since every page shows the cart and most carts are never bought. Round a day to 100,000 seconds (86,400 really); busy hours run about 5× the average.

what           working
orders         10 million ÷ 100,000 s = 100 a second (116 with 86,400)
orders, busy   100 × 5 = 500 a second
carts, busy    500 × 50 = 25,000 reads and changes a second
cart store     100 million carts × about 1 KB = about 100 GB

Carts are the busy path, one small record per request; orders are 50 times fewer, but each touches several warehouses and a card, and must be exact.

The cart: one small record per user

Keep the cart on the server as one record in a key-value store: user id → items. Any device Ana signs in on reads the same key, so the lamp from her phone at lunch is on her laptop at night. Say a cart is about 1 KB: 100 million carts are about 100 GB, and 25,000 a second is 5× one database server, so split the store by user id over a few servers. A cart is always one key, so nothing needs a transaction across two.

A cookie can't follow Ana between devices. Carts stored as orders with the status "cart" would fill the database that must be exact with its busiest data, and a cart shows today's prices, while an order keeps the price agreed at Place order.

An item runs out: steps that undo

Ana's cart has a jacket ($40) and a book ($15) from warehouse A and a lamp ($30) from warehouse B. Each warehouse keeps its own stock, and checkout reserves each item with Flash Sale's conditional update: lower the count only if it's above 0.

step   item        result
1      jacket, A   reserved 3 → 2
2      book, A     reserved 8 → 7
3      lamp, B     0 left: refused
4      book, A     released 7 → 8
5      jacket, A   released 2 → 3
6      order o81   canceled

The last lamp sold a moment ago, so step 3 fails. Warehouse A already committed in its own database, so nothing can be rolled back; instead each finished step has an undo, run newest first. A chain of steps with undos is a saga, as in the Payment System lesson. Nothing was charged: the card is asked only after every item is reserved.

One transaction across the warehouses would need two-phase commit, holding locks in every warehouse while it waits for the slowest. Reservations should also run out on their own, a job putting them back as in Flash Sale, so a checkout that crashes halfway can't keep stock.

Paying: a hold now, the charge when it ships

Ana places the rest again as order o82: $55, one box from warehouse A that ships tomorrow. Checkout asks the card provider to authorize $55: the bank says yes or no at once and sets the money aside, but nothing moves. When the box ships, checkout captures the hold, and only then is Ana charged. A cancel before that just releases the hold: no refund.

Charging at Place order turns every cancel into a refund that takes days to reach her card; charging at shipping without a hold risks a declined card after the box is packed. A hold lasts only days (often about a week), so a later shipment is held again, and several boxes are captured box by box, as parts of one hold where the provider allows it, or one hold per box.

The order's states

An order is a state machine: always in one state, with only some moves allowed.

from        may move to
placed      paid, canceled
paid        shipped, canceled
shipped     delivered
delivered   –
canceled    –

Messages arrive late or twice. Once o82 has shipped, the carrier's "delivered" moves it on; a warehouse retrying "shipped" and a late "hold approved" change nothing; Ana's cancel or new address is refused (offer a return). Each move is one conditional update that names the state it leaves:

UPDATE orders SET status = 'delivered'
  WHERE id = 'o82' AND status = 'shipped'

A repeat changes no rows, so the card is charged once, and when a cancel races a shipment, whichever runs first wins.

Same pattern as Flash Sale

Stock is a count lowered with a conditional update, items are reserved before the money is taken, and Place order carries an idempotency key, so a second press gets the first order back. Flash Sale is one hot row for seconds; checkout runs the same steps all day over millions of products, so no row is hot until a deal makes one product a flash sale again.

Summary

• Scope: many items, several warehouses, charge at shipping.
• Data: one small cart record per user; an order with one status.
• API: PUT /cart, POST /orders with an idempotency key.
• Numbers: about 25,000 cart reads and changes, 500 orders a second at busy hours.
• Services: a key-value cart store split by user id, apart from the orders database.
• Reserving: each item in its warehouse; if one fails, undo the rest: a saga.
• Paying: authorize at Place order, capture when it ships.
• States: placed → paid → shipped → delivered, or canceled; one conditional update per move.