Designing a Ticket Booking System

We are designing a ticket booking system where many users compete for a limited number of seats. The system must never sell the same seat to two users, regardless of how many concurrent requests it receives.

At low load, this is straightforward. At high load — a popular concert, championship match, or major event going on sale — the system can receive far more requests than seats available. The vast majority of users will fail to get a seat. The architecture must handle that gracefully while preserving correctness for those who succeed.

This same no-double-sell requirement underlies concert and live-event ticketing (Ticketmaster-style platforms), movie ticket booking (assigned-seat cinema bookings), and stadium/sports seat reservation — any product where a fixed, identifiable set of seats must be sold exactly once under a demand spike.

Two inventory models

Ticket booking systems generally serve two different inventory models, and it's worth naming both up front rather than assuming every event has assigned seats:

The correctness problem is the same in both models — never oversell scarce capacity — but the mechanics differ: assigned-seat reservation is a per-row atomic transition, while general-admission reservation is an atomic bounded-decrement. This module focuses mainly on assigned seats since they're the harder case, but calls out where general admission simplifies or changes the picture (see General-Admission Inventory in Architecture Deep Dive).

The central distinction

Seat availability shown to users does not need to be perfectly real-time. A seat map that is a few seconds stale is fine for browsing. But the actual reservation operation must always validate the authoritative seat state. These two requirements — fast browsing and correct reservation — require different architectural approaches.

Functional requirements define what users can do. Non-functional requirements define the correctness and scale constraints that shape the architecture.

Functional

Browse events. View seat maps. Select seats (possibly more than one at a time). Temporarily hold selected seats. Complete payment during the hold window. Receive booking confirmation and a ticket. View booking history. Cancel a booking where policy allows it.

Non-functional

An event has a venue with seats. Each seat has a state. Start simple: AVAILABLE or BOOKED.

Unlike bulk product inventory (where you stock many interchangeable units of the same SKU), a seat is unique. Seat A1 is different from seat A2 — different location, view, possibly different price. The identity of each seat matters to the buyer, not just its count.

One seat remains. Two users select it simultaneously. A naive implementation allows both to succeed — double booking.

The problem is that read → decide → write is not a single atomic operation. User A reads AVAILABLE. User B reads AVAILABLE. Both decide to book. Both write BOOKED. The seat is now marked as sold to two people.

Application-level checks alone ('if status is available, then write booked') can never fully close this gap, because the check-then-act sequence itself isn't atomic no matter how carefully it's written in application code. Real protection comes from backing the transition with a database-level constraint or conditional atomic operation — see Atomic Reservation next — so that even a buggy or duplicated application-layer call can't produce two winners.

The fix: make the reservation a single atomic operation that can only succeed for one request, and make it idempotent so retries can't create a second one.

Instead of separate read and write operations, perform a conditional atomic update: transition the seat from AVAILABLE to HELD only if the current state is AVAILABLE. This operation cannot be interleaved with another request's operation on the same seat.

Booking and hold idempotency

A conditional atomic update prevents two different users from winning the same seat — but it does not, by itself, prevent one user's retried request from being treated as a second, independent attempt. A client that times out and retries, or a double-click, must resolve against the same underlying hold rather than attempt a new reservation. The standard mechanism is a client-supplied idempotency key stored durably alongside the hold, so a retry with the same key returns the original result instead of re-running the reservation logic. See Architecture Deep Dive -> Hold Idempotency for the full mechanism.

Multi-seat reservation

Booking more than one seat together adds a requirement beyond single-seat atomicity: all requested seats must succeed together, or (absent an explicit partial-hold feature) none should. A common failure mode is acquiring seats one at a time and only detecting a conflict on the last one, after already holding the others. The fix is to attempt all seats within a single transaction and verify all succeeded before committing — combined with a deterministic lock/acquisition order (for example, sorted by seat ID) across every request, so that two concurrent multi-seat requests touching overlapping seats can't deadlock each other. See Architecture Deep Dive -> Multi-Seat Reservation.

A seat hold gives the user time to complete payment without the seat being taken by someone else. It is not a completed booking.

Without holds, users would need to complete payment in a single instant — or race against other buyers during payment. A hold reserves the seat for a bounded window, giving the user time to pay while preventing others from taking the seat.

A hold is a durable record with its own identity — not just a flag on the seat row. At minimum it needs a hold_id, the owning user/session, the seat(s) it covers, a created_at, an expires_at, and a version. That identity is what lets the system tell 'this specific hold' apart from 'a seat that happens to be marked HELD' — a distinction that turns out to matter enormously once expiry is in the picture (see Hold Expiration).

Abandoned holds must be automatically released. Expiration is itself a concurrency problem — and the way most designs get it subtly wrong is worth walking through carefully.

An expiration mechanism identifies holds that have passed their expiry timestamp and transitions them back to AVAILABLE. But what if the user pays at the exact moment the hold expires? Or what if the release task itself is delayed and runs late, after the seat has already moved on?

A booking is a lifecycle, not a boolean. Explicit states represent what actually happened — and it helps to keep the hold, the booking, and the payment as related but distinct state machines.

SELECTED → HELD (atomic reservation) → PAYMENT_PENDING → CONFIRMED. Failure path: HELD → EXPIRED → seat returns to AVAILABLE. Payment failure: PAYMENT_PENDING → FAILED → seat returns to AVAILABLE.

The central architectural distinction: availability reads and booking writes are two different problems requiring different solutions.

A major event goes on sale. Traffic arrives far above baseline within seconds. The architecture must handle this without collapsing — and 'traffic' here is really four different kinds of load, each with its own bottleneck.

Worked example: one on-sale (illustrative)

These are illustrative planning numbers, not measurements of any real system or event. Assumptions: an arena with 20,000 assigned seats; 1,000,000 users on the seat map at on-sale; each refreshes availability every 5 s; the availability cache or read model serves 99% of those reads; the reservation path for this event sustains about 1,000 hold transactions/s (an assumed figure for one event's partition); an average party of 2 seats; a hold TTL of 10 minutes; each hold writes about 3 rows (two seat rows and the hold); and 70% of holds convert to paid bookings.

What this shows: the four loads differ by orders of magnitude, about 200,000/s of browse, 1,000/s of reservation attempts and roughly 12/s of payments, so one capacity number would be wrong for all of them. Browse is solved by caching, not by the database; the reservation path is the correctness-critical ceiling and the reason the waiting room paces admission to it; and the event sells out within seconds of admission, after which the next burst is the expiry wave returning seats to inventory, which is why expiry must be as safe and idempotent as reservation. Adding application servers changes none of these constraints.

Every component earns its place by solving a specific demonstrated problem. Not every component below is mandatory for every scale of system — a small event without hot-demand on-sales may not need a waiting room at all.