Design e-commerce checkout.

01 · The brief · minute zero

What you are handed

What is really being asked

This is not a scale question in disguise — 10M orders/day is only ~120 orders a second, and saying so out loud is your first senior signal. The real subject is promises under time pressure: checkout promises a unit to a buyer seconds before the money moves, stock is finite and physical, and payment is slow and allowed to fail. The design question is where that promise lives, how long it lasts, and who cleans up when it breaks.

Winning shape: a reservation with a TTL as the promise, an atomic conditional decrement so the last unit is promised exactly once, and payment orchestrated as authorize-now, capture-at-ship — so every step before shipment can be undone cheaply. Candidates fail in the gaps: the read-then-write stock check, the reservation that never expires, the payment that lands after the promise lapsed.

02 · Requirements · minutes 0–8

Four requirements, four constraints

Functional

1. A customer builds a cart that survives devices and sessions; a guest cart merges into the account on sign-in.
2. Placing an order re-prices the cart server-side and reserves stock with a TTL — a visible countdown, not a silent hold.
3. Payment is authorized at checkout and captured at shipment; the order confirms only when reservation and authorization both hold.
4. A customer can cancel before shipment — cancel voids the auth and returns the stock. (Returns after delivery are a different flow — cut it.)

Requirement two hides the interview’s central decision: when to reserve. Reserve at add-to-cart and the ~70% of carts that abandon hold your stock hostage; never reserve and the buyer pays for a unit that’s already gone. Reserve at place-order, with a TTL.

Non-functional

Scope cuts to state explicitly

PSP internals — auth, capture, ledgers, and retries are the payment-system question; here the PSP is a black box with three verbs. Also cut, out loud: search and recommendations, the promo engine’s insides (place the call, skip the engine), multi-warehouse allocation (name the split, cut the routing), returns after delivery, and bot defense beyond the waiting room.

05 · API design · minutes 17–20

Four endpoints and one header that carries the interview

POST /v1/carts/:id/items
POST /v1/orders                 Idempotency-Key: <client-generated>
GET  /v1/orders/:id             → { state, expires_at, … }
POST /v1/orders/:id/cancel

Placing an order sends a cart_id and a payment method — the server re-prices; the client’s total is decoration. The response carries expires_at so the UI can show the reservation countdown honestly. Identity comes from the auth token, never the body. Cancel is a POST, not a DELETE — it’s a state transition with side effects (void, restock), not a row removal. And the payment outcome arrives on the PSP webhook — the 3DS redirect is UX, not truth.

Idempotency-Key semantics — all four cases

Pick a case: what does the server do?

Scope keys per user and bind them to a cart version — a stale tab retrying an old checkout must not purchase today’s cart.

Payment webhooks — four decisions that keep the async edge honest:

• Verify the PSP signature — an unsigned “payment_succeeded” is a free-goods endpoint.
• Dedupe by event id — the PSP will send it twice; confirming twice must be a no-op.
• Webhook vs redirect is a race: whichever arrives first confirms, and both paths are idempotent.
• When in doubt, poll the PSP — for auth state, the PSP is the source of truth, not your last event.

08 · Traps & misconceptions

Seven claims that fail this interview

Each claim below is wrong. Read the claim, decide why it fails — then open it. These mirror the misconception patterns the simulator probes.

Failure drills — would you catch it?

Four attack scenarios from the engine, tagged by severity. Commit to an answer before opening the fix.

10 · FAQ

Common questions

How hard is the e-commerce checkout interview question?

Medium — the concepts (reservations, TTLs, auth vs capture, one conditional UPDATE) are each simple; the difficulty is sequencing them so every failure lands in a cheap-to-undo state. It’s a favorite senior-level screen because the arithmetic — 10M orders/day is only ~120 per second — quietly tests whether you design for real numbers or imagined scale.

Should inventory be reserved at add-to-cart or at checkout?

At place-order (or checkout start), with a TTL — never at add-to-cart. Roughly 70% of carts abandon; reserving on add turns browsing into a denial-of-service against your own stock. The reservation carries a visible countdown, and a sweeper returns expired holds to available.

What is the single most common mistake?

Reading the stock level, checking it in application code, and decrementing in a second statement. Two concurrent buyers both pass the check and the last unit sells twice. The fix is one conditional UPDATE with the sufficiency check in the WHERE clause — the check and the decrement become atomic.

Do I need to shard the database?

No — and saying so is a signal, not a cop-out. 10M orders/day is ~120 writes per second, comfortable for one well-run Postgres, and keeping stock, reservations, orders, and the outbox together is what makes the confirm a single ACID transaction. The hot-SKU problem is contention on one row — sharding doesn’t fix that either.

How should I budget the 45 minutes?

Roughly: 8 min requirements (say the contract), 5 estimation (do the division out loud), 7 entities + API (the reservation and the idempotency key), 10 high-level design (reserve → authorize → confirm → capture-at-ship), 15 deep dives — the last unit, the TTL-vs-payment race, and the drop are where hire / no-hire separates.

Related questions