Design an e-commerce cart and inventory system

An online shop on an ordinary day: millions browsing, carts filling and being forgotten, and a few thousand orders an hour. The flash sale (D24) is about surviving one extreme moment. This design is about the everyday hard parts: never selling stock you don't have, never losing a cart, and making checkout a sequence of steps that can fail halfway without leaving a mess.

1. The prompt

"Design the shopping cart, inventory and checkout for a large online store."

What makes it hard:

• Two kinds of consistency in one product: a product page can show "in stock" a few seconds late; checkout must never sell the last unit twice.
• Checkout spans several services (inventory, payment, orders) that can each fail independently.
• Most carts are abandoned, so anything held for a cart must be let go.

2. Frame the problem

3. What it must do

1. A shopper can add items to a cart, as a guest or logged in, from any device, and the cart is still there tomorrow.
2. A shopper can check out: stock is reserved, payment taken, an order created, exactly once.
3. Everyone sees availability on product pages, close to real time.

Not now: search and recommendations, the payment system itself (D16), shipping and returns, the flash-sale extremes (D24), marketplace sellers.

4. How well it must do it

5. Numbers that change the design

Illustrative numbers. The abandonment rate is in the commonly reported range for online retail.

6. The nouns

• Product (catalogue) and SKU (a sellable variant).
• Cart and cart lines.
• Stock per SKU per warehouse, and reservations against it.
• Order with lines, price snapshot and a status.

cart          cart_id (session or user) → lines[(sku, qty)], updated_at        (key-value, TTL 30 days)
stock         (sku, warehouse) → on_hand, reserved, version                   (relational, sharded by sku)
reservation   reservation_id, checkout_id, sku, warehouse, qty, expires_at, state (held | committed | released)
order         order_id, user_id, checkout_id (unique), lines[(sku, qty, unit_price)], total, status
outbox        event_id, aggregate, type, payload, published_at                (same database as orders)

available = on_hand − reserved. A reservation succeeds only if it stays ≥ 0.

7. The contract

GET    /v1/products/{id}                         → {…, availability: "in_stock" | "low" | "out"}
PUT    /v1/cart/lines/{sku}   {qty}               → cart          (cart id from session or token)
DELETE /v1/cart/lines/{sku}                       → cart
POST   /v1/checkouts           {}                 Idempotency-Key: …
       → 201 {checkout_id, lines, prices, total, expires_at}      (stock reserved)
POST   /v1/checkouts/{id}/pay  {payment_method}   Idempotency-Key: …
       → 200 {order_id, status: "confirmed"} | 409 {reason: "reservation_expired" | "payment_declined"}

The user comes from the session token. Every state-changing call takes an idempotency key, so a retried tap on "Pay" can't create a second order.

Data flow: cart → start checkout (snapshot prices, reserve stock) → authorise payment → create order and commit reservations (one transaction, plus an outbox event) → capture payment → events to fulfilment, email and the availability read model.

8. First working version

A catalogue service behind caches, a cart service on a key-value store, an inventory service on a relational database, an order service, and the payment service.

8.1 Adding to the cart

A write to the cart store keyed by the cart id; no inventory involved. The page shows availability from the read model. On login, the guest cart's lines are merged into the user's cart (sum quantities, cap at stock limits) and the guest cart deleted.

8.2 Checkout

Starting checkout reserves every line atomically per SKU (a conditional update: UPDATE stock SET reserved = reserved + q WHERE sku = ? AND on_hand - reserved >= q). If any line fails, the others are released and the shopper sees which item ran out.

8.3 Abandoned checkouts

A sweeper releases reservations past their expiry. The paying step re-checks expiry, so a slow payment after the timeout is rejected cleanly or re-reserves if stock is still free.

9. Make it hold up

9.1 When to hold stock, and for how long never oversell

Rows are sharded by SKU, so contention is per SKU. A very hot SKU becomes the flash-sale problem: see D24 for queues and pre-split stock.

9.2 Checkout as a saga exactly once

9.3 Retries and double taps exactly once

The phone times out after "Pay" and the shopper taps again. The idempotency key on the request maps to the same checkout, and checkout_id is unique on orders, so the second request returns the first result. Calls to the payment service carry the same key, so a retried authorisation isn't a second charge. Inventory commits are keyed by reservation id and are no-ops the second time.

9.4 Availability for 60,000 page views a second product pages

9.5 Carts that always accept writes cart writes

Carts are per user, small, and rarely contended: a partitioned, replicated key-value store fits. Amazon's Dynamo paper describes choosing availability for the cart: accept the write even during failures, and merge divergent versions later (union of lines), occasionally resurrecting a deleted item. Today, a store with single-key strong consistency per partition plus a cache usually suffices; mention the trade-off either way. Expire guest carts after a period; keep logged-in carts longer.

9.6 Many warehouses never oversell · cost

Availability on the page is the sum across warehouses that can ship to the shopper's region. At checkout, an allocation step chooses warehouses (nearest that has every item, else split shipments with a cost rule) and reserves there. If a warehouse's count turns out wrong (a damaged item), the order is re-allocated or the line cancelled, which is why physical counts and the system are reconciled daily.

9.7 The whole design after the deep dives

10. Interviewer follow-ups

11. When things break

12. Wrap-up and the clock

Trade-offs we made:

• Reserve at checkout, not at add-to-cart, with a timeout we tune.
• Strong consistency only where money and stock are decided; seconds of staleness on product pages.
• A saga with authorise-then-capture instead of distributed transactions.
• Idempotency keys on every write that matters.
• A separate read model for availability.

What we'd watch: checkouts started vs completed · reservations expired before payment · reservation conflicts per SKU · saga steps compensated · read-model lag · oversell incidents (target zero).

At 10×: more cache and cart capacity; checkout still fits sharded databases; hot SKUs move to the flash-sale design.

Common mistakes:

• Reserving stock at add-to-cart.
• Product pages querying the inventory database.
• A distributed transaction across services and the payment provider.
• Capturing payment before the order exists.
• No idempotency on "Pay".
• Storing prices in the cart.

13. Try it, check yourself, read more

Reservation timeout tuner. 60 units, 300 shoppers starting checkout over 60 minutes (more than the stock can serve). Some abandon; payers take 4 minutes to pay. Set the hold time and the abandonment rate, and see sales, shoppers turned away while stock was only held, and payers whose hold expired.

Green = sold, amber = held by open checkouts, light = free. A payer whose hold expired re-reserves if stock is free, otherwise fails at payment. A smooth flow model (5 shoppers a minute), illustrative numbers.