Reservation Then Commit Pattern: Prevent Overselling at Scale (2026)

Q: What is the reservation-then-commit pattern?

Reservation-then-commit is a two-phase pattern for selling scarce inventory without overselling under concurrent demand. Phase 1 (Reserve) atomically decrements available stock and creates a time-bounded hold record when the user expresses intent to purchase; Phase 2 (Commit) converts the hold into a permanent sale when payment succeeds, or releases it if payment fails or the TTL expires. The pattern eliminates the check-then-decrement race condition that causes overselling in naive designs by closing the race window — the decrement happens at intent time, not at completion time. It is the standard solution for any scarce-inventory system: ticketing, hotels, restaurants, ride-hail matching, retail flash sales, vaccine appointments, and GPU reservations.

Q: How long should a reservation TTL be?

Match the TTL to the realistic completion time of the user flow. Standard e-commerce checkout takes 2 to 10 minutes from add-to-cart to order placement; a 10-minute TTL is the typical default. Complex booking flows with seat selection and add-on services may need 15 to 30 minutes; enterprise procurement with approvals may need hours or days. Setting the TTL too short causes user frustration ("the seat I selected disappeared while I was reading"); setting it too long causes lost capacity ("twenty seats are reserved and idle, the event is sold out, but ten will eventually expire"). Different user segments can have different TTLs — guest checkout 10 minutes, returning customer 20 minutes, corporate buyer 60 minutes. Always show a visible countdown to the user to reduce abandonment and calibrate expectations.

Q: What are the main implementation patterns for reservations?

Three production patterns. (1) Database row locks with explicit reservation table — most common; uses serialisable transactions on a reservations table; acceptable for up to a few thousand reservations per second. (2) Redis with Lua script for atomic decrement-and-hold — for higher throughput; a single Lua script atomically checks-decrements-creates-hold-with-TTL; tens of thousands per second per Redis instance; must persist to durable store for audit trail. (3) Dedicated reservation service with event sourcing — for very large systems (airline reservations, major ticketing platforms); event-sourced ledger with full audit and complex business rules; high implementation complexity. Avoid the anti-pattern of distributed locks (Redis SETNX, ZooKeeper) for the per-reservation hot path — use locks for metadata operations, atomic operations for reservations.

Q: How does the reservation pattern compose with sagas and idempotency?

The Saga pattern uses reservations as its compensable steps — when a multi-service checkout saga (reserve inventory, charge payment, allocate shipping) fails at a later step, the inventory step's compensation is to release the reservation, which is a clean reversal because no commit has yet occurred. Without reservations, the inventory step would have to be a permanent decrement requiring a full restore as compensation, including audit trail of the reversal. Idempotency keys protect every reservation lifecycle operation (reserve, commit, release) — network errors during these operations cause client retries, and non-idempotent retries produce duplicate reservations or commits-on-released holds. Each operation accepts an idempotency key; the server stores the key with the result and returns the same result on retry without re-executing.

Q: What happens when a user tries to commit after the reservation has expired?

There are two options: (a) reject the commit because the reservation expired (correct in terms of the contract but produces user-visible payment-without-inventory failures), or (b) allow the commit if stock is still available. Option (b) silently creates race conditions because between the expiry and the commit attempt, the same inventory may have been reserved by someone else. The right answer is to attempt the commit but treat it as a re-reservation — atomically check if stock is currently available; if yes, commit and accept; if no, reject and refund the payment. This produces correct semantics (no overselling, no payment without inventory) without surprising the user with arbitrary timing-dependent failures. The implementation is a small extension to the commit endpoint that performs the atomic re-check before committing.

Q: What are the most common reservation pattern anti-patterns?

Holding a database row lock across the payment call: blocks every concurrent transaction on the same inventory; under load the database becomes the bottleneck. The reservation record itself is the lock-free representation of "this seat is held." Never combine row locks with payment-call latency. No expiry on holds: produces permanent inventory ghosts as users abandon flows without releasing; always set a TTL and run a sweeper. Computing available count from a separate counter that drifts: any operation that fails to update the counter creates invisible drift, leading to overselling or fake sold-out states; compute available from canonical sources (total minus active holds), cache only as an optimisation. No idempotency on reserve, commit, or release: flaky networks produce retries that create duplicate reservations or duplicate commits. Allowing commit on an expired hold without re-checking availability: silently creates race conditions and overselling.