Design ecommerce checkout and inventory reservation

01Choose a checkout that can be completed coherently

Design physical-goods checkout with several cart lines and no backorders. Initially, keep inventory where all requested lines can commit in one database transaction. Customers browse, accept a server-calculated quote, reserve all requested lines, authorize payment and receive an order outcome. Shipping follows confirmed capture. Exclude marketplace settlement and atomic checkout across independently owned warehouse databases from the baseline.

Cart C7 requests two mugs M9 and one notebook N2. There are three sellable mugs. Another customer also wants two. Only one of those mug reservations can succeed before replenishment. A cart is shopping intent, not a reservation; a product page may still display stale availability when the definitive checkout decision rejects a request.

Stock equation

available = onHand − reserved − allocated

Every quantity must remain nonnegative. This equation exposes mistakes that a vague stock-service box can hide.

Assume a ten-minute initial hold, checkout admission below 300 ms p95 and 95% of admitted checkouts reaching confirmed allocation within three seconds when payment authorization and inventory dependencies are healthy. A payment timeout may keep the order pending longer. Choose clear stock and money outcomes over pretending every timeout is a definitive failure.

Ask whether all cart lines share one inventory authority, whether backorders are allowed, and whether confirmation means authorized, captured or ready to ship. This answer uses no backorders and one inventory transaction domain: confirmation follows allocation, while dispatch waits for known capture success.

02Functional requirements

1. Accept a checkout. Validate the authenticated customer’s cart and server-calculated quote, then create or recover one pending order.

2. Reserve the whole cart. Hold every requested line together or reject the request without leaving partial reservations; expire unconverted holds under a defined deadline.

3. Take payment and fulfill. Authorize payment, convert valid holds to allocations, capture once and authorize shipment only after known capture success.

4. Recover and cancel. Expose authoritative order progress, retry unfinished effects and handle cancellation or compensation according to the current stock, payment and dispatch state.

03Non-functional requirements

These are illustrative interview assumptions, not product facts or measured benchmarks. Confirm them before choosing components, then validate the completed design under the stated workload. Here p95 means the 95th-percentile latency: 95% of measured requests take no longer than that value. Report errors and rejected work alongside latency; a fast failure is not a successful outcome.

1. Workload and local latency. Plan for one million orders/day and a 1,000 orders/s peak with five lines each. Target durable checkout admission below 300 ms p95; measure hot-SKU contention separately from aggregate throughput.

2. Hold and completion timing. Choose a ten-minute initial hold. As an objective, aim for 95% of admitted checkouts to reach confirmed allocation within three seconds when payment authorization and inventory dependencies are healthy. Provider uncertainty remains pending and is reported separately, not treated as a guaranteed rejection or completion.

3. Inventory and effect correctness. Keep onHand, reserved and allocated nonnegative, with available = onHand − reserved − allocated. No overselling, partial all-line hold, duplicate capture or duplicate shipment is permitted through supported retries.

4. Durability and safe availability. Require acknowledged orders, stock transitions and effect identities to survive one database-node failure through synchronous durable replication and safe failover. Refuse new inventory decisions without safe authority; retain allocations while capture is unknown.

5. Security and scope. Authenticate ownership, validate positive quantities and frozen quote terms, and restrict stock/refund actions to trusted actors. Independent warehouse transactions and regional stock budgets require an explicitly changed contract.

04Trace one complete order before splitting services

Start with a checkout application, a relational database containing orders and inventory, a payment adapter and a durable background worker. The API validates cart version, quantities, quote and customer ownership. One transaction claims request key K4, locks all stock rows in stable order, checks the complete set, creates pending order O401 and its holds, and reserves the quantities. If any line lacks stock, the transaction rolls back all lines.

M9 changes from onHand 3, reserved 0, allocated 0 to 3, 2, 0. Available stock becomes one. The competing request for two mugs fails against current authority even if its browser still shows three.

The worker records a stable payment authorization operation before calling the provider outside database locks. After known authorization, a transaction verifies every hold is still valid, converts them to allocations and confirms the order. Capture is a separate stored payment operation. Only known successful capture permits the later fulfillment authorization.

If the application dies after any local commit, durable pending-work records allow another worker to continue the same order. The whole user flow works with one database; a queue or independent warehouse service is introduced only when a measured or organizational boundary justifies the additional coordination.

05Size line transitions and hot-stock contention

Assume one million orders/day, about 11.6/s on average, with a 1,000 orders/s peak and five lines per order. The peak requires roughly 5,000 reservation-line operations/s. Successful checkout also converts holds to allocations, so that is about 10,000 line transitions/s before releases, shipment, replenishment and retries.

Ten million carts at 2 KB each occupy 20 GB logically. Ten million stock rows at 96 bytes each occupy about 960 MB before indexes and copies. Small raw stock storage does not imply easy concurrency: hundreds of requests may compete for the same three mugs while most rows remain idle.

A stock row held for an illustrative 20 ms per contending transaction has a simple serial ceiling near fifty transactions/s before other work. Holding that lock through a 500 ms payment call could reduce the ceiling to about two/s. This is why network calls must occur outside stock transactions.

At 1,000 admitted orders/s, ten-minute holds could produce 600,000 active workflows and three million line holds. The stock unavailable to other buyers while held matters more than the hold records’ size. Bound per-customer holds and flash-sale admission. A shorter deadline releases stock sooner but rejects more slow legitimate checkouts; choose it using measurements of how long slower checkouts take.

06Freeze commercial terms and name each effect

Interfaces

Create or recover the worked checkout

POST /checkouts

Checkout request with accepted cart and quote versions

{
  "key": "K4",
  "cartId": "C7",
  "cartVersion": 3,
  "quoteId": "Q7",
  "quoteVersion": 2
}

The version numbers and quote ID instantiate the existing version checks: they must match the customer’s accepted cart and quote. Authentication supplies the customer identity.

Stored records

Reusing K4 with the same cart and quote returns O401. Different parameters under K4 conflict. Obtain customer identity from authentication, validate positive bounded quantities and never accept browser-supplied prices as authority. If a quote has changed or expired before acceptance, present new terms rather than silently charging another amount under the old key.

An order ID alone is not a sufficient key for every operation: authorization, capture, refund and shipping are different effects. Name and persist those identities separately so retries cannot merge unrelated actions or create another charge.

07Explain each stock movement with the same equation

Follow the same two mugs through each state:

Release is a guarded state transition, not “add quantity back.” Releasing a held line subtracts its quantity from reserved once. Releasing an allocated line is permitted only through a valid pre-dispatch cancellation or compensation and subtracts from allocated once. Repeating either request returns the prior outcome rather than increasing available stock again.

Expiry and allocation lock the same hold and stock records in a consistent order. If allocation wins while the hold is valid, expiry later sees allocated and does nothing. If expiry wins, it marks the hold terminal and removes its reserved quantity; allocation then fails. Check the authoritative database clock after locks are acquired, not a stale timestamp taken before a long wait.

Replenishment and inspected returns also need stable source identities. Replaying a warehouse receipt must not add stock twice. Local constraints and periodic reconciliation compare counters with the underlying hold/allocation records to catch implementation defects.

08Keep payment uncertainty from corrupting stock decisions

Before calling the provider, persist an authorization attempt with immutable order amount, currency and identity. The provider call runs outside database locks. A timeout leaves the attempt unknown. Query or retry the same operation under the provider's supported contract; a new request identity may authorize or charge again.

Once authorization is known, validate all holds and convert them to allocations in the database transaction before confirming the order. If a hold expired first, fail confirmation and release remaining holds. Void an unused authorization under its own recoverable operation. Canceling an authorization is a new compensating action; it does not erase the earlier provider operation.

Capture then uses one stored operation. Until capture is known successful, shipping remains blocked. If its outcome is unknown, retain the allocations and escalate reconciliation rather than applying the ordinary hold timeout to possibly paid inventory. Allocation and temporary hold are different states with different release policies.

If capture definitively fails, cancel the unshipped order and release allocations through guarded transitions. If a late success is discovered during cancellation recovery, refund through the payment subsystem under a stable identity before reporting fully resolved compensation. Provider deduplication windows are finite; beyond them, reconcile instead of assuming a local key permits safe repeated calls forever.

09Serialize cancellation with the permission to ship

Known capture success is necessary but not sufficient to dispatch a shipment. In one transaction on the order’s owning database, verify all required allocations, current order state and capture outcome, then mark fulfillment authorized and create a unique shipment intent. This is the point after which ordinary cancellation cannot simply free those allocations.

A cancellation that commits first prevents fulfillment authorization and starts the appropriate stock/payment cleanup. If fulfillment authorization commits first, cancellation must obtain a definitive no-dispatch result from the warehouse or move into a return/refund process. A delayed shipping status message does not prove that the parcel has not already left.

The warehouse consumes the shipment intent under its stable identity. Repeated delivery must not dispatch another parcel or decrement physical stock twice. The inventory transition checks the referenced allocation before changing onHand and allocated together. Saving the shipment request alone does not prove that the warehouse dispatched it once.

Keep customer states understandable: awaiting payment, confirmed with capture pending, ready for fulfillment, compensating, canceled or shipped. Support tools can inspect detailed step identities without exposing payment secrets. Notifications communicate committed state changes; they do not decide whether stock is available, payment succeeded or cancellation beat dispatch.

10Scale browsing and admission before splitting transactions

Cache product data and advisory availability, and publish order-history projections for read-heavy pages. Those views may lag; checkout approval and disputed status read the current owning database. Versioned events keep older pending projections from overwriting newer confirmed state. A newly created order remains directly retrievable even before its history list catches up.

Protect flash-sale stock with bounded admission and per-customer quotas. Reject or queue excess contenders before they acquire partial holds elsewhere. Reserve worker/database capacity for reconciliation and release, because starving old workflows can trap real sellable inventory even while new-request latency looks acceptable.

Keep all-line transactions in one database while that ownership is practical. Distribute independent shops or stock pools only when their checkout contract remains compatible with the transaction boundary. More API replicas do not improve a single contended stock row, and read replicas cannot independently sell the same physical units.

If independent warehouses become required, the design changes to a durable sequence of local reservations and compensation, often called a saga. The order can be temporarily pending with some lines held. Confirm only after every required allocation exists, and explicitly recover failed or uncertain steps. The single-database baseline's simultaneous all-line commit no longer applies merely because the coordinator calls several APIs.

11Recover the same order and effect after each crash

Use synchronous durable database replication and safe failover to preserve acknowledged orders, stock transitions and effect identities across one database-node failure. A stale or independently writable copy cannot approve the last unit. Backups must include request identities, payment references and pending work, not merely order display rows.

For a future distributed warehouse design, cancellation also has to handle a delayed reserve command whose result is unknown. Use the same stable line identity and a durable terminal cancellation record so an old reserve cannot arrive later and recreate an abandoned hold. This is one reason to keep the initial transaction domain intact until the independent ownership benefit justifies a fuller workflow protocol.

Recovery should prioritize oldest pending and compensating work, with bounded retry and clear escalation. A timeout is a reason to resolve the known operation, not permission to start a fresh checkout.

12Audit stock ownership and explain the tradeoffs

Monitor hot-SKU lock wait, reservation age, oldest pending order, capture uncertainty, compensation backlog and duplicate shipment suppression. Reconcile inventory counters against active hold and allocation records. A healthy checkout HTTP success rate does not prove that stock is neither stranded nor oversold.

Test two customers requesting two of three mugs, a retry after hold commit, expiry racing allocation, capture reply loss and cancellation racing fulfillment authorization. Crash the worker between every remote success and its local result record. Restore data and replay old messages to ensure identities still prevent additional financial or inventory effects.

Authorize stock movements to trusted services, restrict refund/support actions and avoid sensitive addresses or payment tokens in ordinary logs. Quotas also prevent bots from immobilizing inventory through unpaid reservations. Validate returns before replenishing sellable stock; a requested return does not immediately create a physical unit.

The main tradeoff is temporary inventory occupancy in exchange for a recoverable checkout. A longer hold helps slow legitimate users but strands more stock. Independent warehouses improve autonomy but introduce pending and compensation states. Disjoint regional stock budgets can allow local checkout during partitions, but may leave unsold units stranded in another region. Choose these changes deliberately rather than promising the same simple atomic guarantee under every topology.

13Check the design against its requirements

Use the numbered requirements to check the final design. FR refers to the functional list; NFR refers to the non-functional list. Performance rows specify tests still required, not achieved benchmark results.

14Rapid revision

Remember: Holds and allocations both claim stock. An unknown capture keeps its allocation until recovery determines whether money moved.

Close with the three-mug equation at each stage and a lost payment response. Mention that the selected single transaction domain gives simple all-line inventory atomicity; independent warehouses are a meaningful extension requiring durable partial progress and compensation, not just more services.

Recall the key ideas

Answer from memory before opening each card. Explain why the choice works and what it costs. Revisit missed cards tomorrow.