Checkout reservations: hold a place while the customer pays

What does the reservation capability do?

It closes the gap between choosing a place and paying for it, in both directions. Without holds, two customers can buy the last place; with permanent holds, abandoned baskets block real capacity. The reservation flow does neither.

• Time-boxed holds. Starting checkout writes a reservation with an expiry timestamp. The window defaults to 15 minutes and is a configuration value per deployment.
• Holds count, expired holds do not. Availability is confirmed bookings plus unexpired holds. A lapsed hold stops counting immediately, because every check compares the expiry timestamp with the current time. Correctness never depends on a background sweep.
• Guarded confirmation. After payment, the confirm step promotes the hold to a booking and increments the booked count in one transaction. An expired hold is refused with an explicit outcome rather than silently oversold.
• Idempotent by design. A repeat reserve call returns the customer’s existing hold. A replayed confirmation (payment webhooks retry) returns success without double-counting.
• Serialised per occurrence. The capacity check and the hold write happen under a per-occurrence lock, so two customers cannot race for the last place. When the session is genuinely full, the same transaction offers a waitlist position instead.

How it behaves at the edges

The edge cases are where booking systems usually leak, so they are worth stating plainly. A customer completing 3-D Secure just after their hold lapses gets a definite reservation-expired response, not a phantom booking. A double-tapped book button returns one hold, not two. And a stalled background job blocks nothing, because release is a property of how availability is read.

The concurrency design behind this, and how it holds up during on-sale spikes, is covered in capacity and overbooking and in our guide on handling high-demand bookings without overselling.

Why it matters

Overselling costs refunds, apologies, and trust; phantom fullness costs silent revenue. Both failure modes disappear when holds are explicit records with expiry timestamps and confirmation is a guarded transition. The companion guide below sets out the full design, including the five demonstration tests to put to any booking vendor.