Marketplaces & booking
Checkout - holding stock you have not sold yet
reserve, charge, commit, unwind
What this board gets wrong on purpose
The tension
The reservation is held in one store and the charge happens in another, so there is no transaction across them - only a compensating message. That message is the weak point and it is drawn as a queue with no dead-letter: if the release worker crashes mid-batch, or the compensation event is dropped, the stock stays held with nothing left to release it, and the only thing that ever recovers it is the TTL sweeper running on a clock nobody alerts on. The sweeper is a correctness hazard in the other direction too - it will happily expire a hold belonging to a payment still in a 3-D Secure redirect, so a shopper who authenticates slowly gets charged for a unit that was given away while they were typing a code. The idempotency store makes a retried POST safe and does nothing at all about a retried capture at the processor.
1 · Requirements
Checkout is the twenty seconds between a cart and an order. Everything before it is browsing and everything after it is logistics; this is the only part where the system makes a promise it can be sued over.
Ask these before designing
- Is overselling ever acceptable? For a marketplace of one-off used goods, never. For a retailer with 400 units in four warehouses, a 0.1% oversell that is fixed by a back-order is cheaper than the contention a strict hold costs. The answer changes whether reservations exist at all.
- Authorise at order, or capture at order? Authorising holds the funds and captures at ship; capturing takes the money now. Card scheme rules give an authorisation about 7 days, so an item that ships in 3 weeks cannot be authorised at checkout, and the saga grows a re-authorisation step.
- How long is a hold? 15 minutes covers a card form. It does not cover a bank redirect on a bad mobile connection, and it does not cover "pay by bank transfer".
- One warehouse or many? Availability is per fulfilment centre. A single global count is a lie the moment you have two.
- Digital goods in the same cart? They have infinite stock and no hold, which means a mixed cart has two different commit rules.
Functional
- Place an order from a cart: price it, hold the stock, take payment, commit.
- A retried request must not place a second order, and must not take a second payment.
- Stock held by a failed or abandoned checkout must come back, without a human.
- Cancel before dispatch: release stock and refund.
- Every order line records what was paid, not what the catalogue says today.
Non-functional
- Correctness beats availability on this path. Refusing an order is a bad day. Selling one unit twice is an apology, a refund, and a support cost of roughly 40x the item margin.
- p99 under 2.5 s for POST /orders end to end, of which the card network is 1.2 s and is not ours.
- 99.95% for checkout, against 99.99% for browse - checkout is allowed to be the less available half because it is the half that must be right.
- Peak is 20x average and it is a calendar event, not a surprise. Capacity is provisioned for the 20x, not autoscaled into it.
- Hold release must complete within 60 s of a failure at p99, because a held unit is unsellable inventory.
Explicitly out of scope
Catalogue and search, pricing and promotions, tax calculation, fraud scoring, returns. Each is a real service; none changes the shape of the reservation problem.
The rest of this board
Available on Tier Slate
This page publishes the question. The answer — 5 more written pages, an 8-step narrated walkthrough and a 5-table schema — is the board itself, and it opens in Tierslate.
- 5written pages
- 8walkthrough steps
- 5tables33 columns
5 pages behind this one
- Capacity estimation
- Storage estimation
- Availability
- How it works
- Deployment plan
More boards
Two-sided systems where inventory must not be sold twice.