Design a Ticket Booking System Without Overselling

At 12:00 noon, tickets for a cricket final go on sale. The stadium holds 50,000 seats. A million people are waiting, refreshing their screens. In the first few seconds, tens of thousands of them click on the same few hundred seats behind the bowler's arm. Every one of those clicks is a race. If the system lets two people buy the same seat, two families travel across the country for a seat only one of them can sit in.

Ticket booking is the clearest example of contended, scarce inventory, and it brings together two very different problems: correctness (never sell a seat twice, never charge without a ticket) and traffic (a burst a thousand times normal, much of it from bots). This case study solves both.

• How to model seats, holds and bookings.
• How to claim seats atomically, including several seats at once.
• Holds with expiry, and how expiry is enforced.
• An idempotent payment-and-confirmation flow, and the late-payment problem.
• How to survive a big on-sale with a virtual waiting room.
• Handling hot inventory, bots and failures.

Build a ticketing platform for events (concerts, matches, shows). Events have either reserved seating (pick seat C14) or general admission (any of 5,000 standing tickets). Users browse events, view seat availability, select seats, hold them while they pay, and receive tickets. Popular events go on sale at a fixed time and sell out in minutes.

Functional requirements: list and search events; show seat availability; hold seats (or a quantity for general admission) for 10 minutes; pay and confirm a booking; issue tickets; cancel within rules.

Non-functional requirements

Normal days:

50,000 bookings/day across all events -> under 1/s on averageBrowsing: 5 million event and seat-map views/day -> about 60/s average

A big on-sale (assumption):

1,000,000 people in the first minutes; each refreshes the seat map and tries several holdsSeat-map requests: 200,000/s at the peak momentHold attempts: 50,000/s, mostly targeting a few thousand "best" seatsInventory: 50,000 seats, so at most 50,000 successful holds (plus re-holds after expiry)

Conclusions: the data is tiny (tens of thousands of seat rows per event); the difficulty is contention (many writers on the same few rows) and bursts a thousand times normal traffic. Correctness depends on the inventory store; survival depends on controlling how many requests reach it.

GET  /v1/events?city=chennai&from=2026-11-01          -> list (cacheable)GET  /v1/events/{eventId}/seats                        -> seat map with availability (cached for 1-2 s)POST /v1/events/{eventId}/holdsIdempotency-Key: 8b1e...{ "seat_ids": ["C14", "C15"] }                         (or {"section": "GA-East", "quantity": 4})201 { "hold_id": "h_41", "seats": ["C14","C15"], "expires_at": "...12:10:00Z", "amount": 900000 }409 one or more seats no longer available (with the conflicting seats)422 exceeds per-user limitPOST /v1/bookingsIdempotency-Key: 2f7a...{ "hold_id": "h_41", "payment_method_token": "pm_..." }202 { "booking_id": "b_77", "status": "payment_pending" }   -> becomes "confirmed" or "failed"410 hold expiredGET  /v1/bookings/{bookingId}                           -> status and ticketsDELETE /v1/holds/{holdId}                               -> release earlyPOST /v1/bookings/{bookingId}/cancellation              -> refund per rules

Amounts are integers in the smallest currency unit (paise). Holds and bookings take idempotency keys, because users double-click and mobile networks retry (article 20).

CREATE TABLE seats (    event_id         BIGINT NOT NULL,    seat_id          VARCHAR(10) NOT NULL,    section          VARCHAR(20) NOT NULL,    price_paise      BIGINT NOT NULL,    status           VARCHAR(10) NOT NULL DEFAULT 'free',   -- free, held, booked    hold_id          BIGINT,    hold_expires_at  TIMESTAMPTZ,    booking_id       BIGINT,    PRIMARY KEY (event_id, seat_id));CREATE TABLE holds (    hold_id     BIGINT PRIMARY KEY,    event_id    BIGINT NOT NULL,    user_id     BIGINT NOT NULL,    expires_at  TIMESTAMPTZ NOT NULL,    status      VARCHAR(12) NOT NULL,   -- active, converted, released, expired    idem_key    VARCHAR(64) NOT NULL,    UNIQUE (user_id, idem_key));CREATE TABLE bookings (    booking_id  BIGINT PRIMARY KEY,    hold_id     BIGINT NOT NULL UNIQUE,      -- one booking per hold    user_id     BIGINT NOT NULL,    event_id    BIGINT NOT NULL,    status      VARCHAR(16) NOT NULL,        -- payment_pending, confirmed, failed, cancelled, refunded    payment_id  VARCHAR(64),    amount_paise BIGINT NOT NULL);-- General admission: one counter row per section (or several buckets, see section 8).CREATE TABLE ga_inventory (    event_id  BIGINT NOT NULL,    section   VARCHAR(20) NOT NULL,    bucket    INT NOT NULL,    remaining INT NOT NULL CHECK (remaining >= 0),    PRIMARY KEY (event_id, section, bucket));

The seat row is the single source of truth for each seat. The CHECK (remaining >= 0) makes overselling general admission impossible at the database level. Partition key: event_id, so all of an event's inventory lives on one database (or one shard), where strong consistency is cheap.

Clients -> Load balancer -> Booking API -> PostgreSQL (events, seats, holds, bookings)                                        -> Payment provider

The naive hold handler reads the seats, checks they are free in application code, and updates them. Article 14 showed exactly how that fails: two requests read "free" before either writes "held". The baseline works in testing and double-books under load.

1. Races on seats (check-then-act): double holds and double bookings.
2. Multi-seat consistency: a user wants C14 and C15 together; getting only one is useless.
3. Holds that never end: a user closes the app; seats stay held.
4. Payment timing: the payment can take seconds or fail ambiguously, and can even succeed after the hold expired.
5. On-sale bursts: 50,000 hold attempts per second on a few thousand rows, plus 200,000 seat-map reads per second.
6. Bots grabbing seats faster than people.

Holds use a conditional update that both checks and claims, inside one transaction:

BEGIN;UPDATE seatsSET status = 'held', hold_id = :hold_id, hold_expires_at = now() + interval '10 minutes'WHERE event_id = :event_id  AND seat_id IN ('C14', 'C15')  AND (status = 'free' OR (status = 'held' AND hold_expires_at < now()));-- If the number of rows updated is not 2, ROLLBACK: someone else has one of the seats -> 409.INSERT INTO holds (hold_id, event_id, user_id, expires_at, status, idem_key)VALUES (:hold_id, :event_id, :user_id, now() + interval '10 minutes', 'active', :idem_key);COMMIT;

• The WHERE clause makes the check and the claim one atomic step per row; the row-count check makes the hold all-or-nothing across seats.
• Expired holds count as free (lazy expiry), so seats come back the moment their hold lapses, even before any cleanup job runs.
• Updating several rows can deadlock with another transaction updating the same rows in a different order; PostgreSQL detects and resolves deadlocks by aborting one transaction (Explicit Locking). Updating rows in a consistent order (by seat_id) avoids most of them; retry the rest.
• PostgreSQL's default isolation level (Read Committed) is sufficient here because each row's check and update happen in one statement (Transaction Isolation); no application-level read precedes the write.

General admission uses a conditional decrement instead: UPDATE ga_inventory SET remaining = remaining - 4 WHERE event_id = ? AND section = ? AND bucket = ? AND remaining >= 4.

• Every read of availability, and every confirmation, treats held with hold_expires_at < now() as free.
• A scheduled job (article 37) runs every minute: it marks expired holds expired, resets their seats to free (with a conditional update that only touches seats still held by that hold), and returns general-admission quantities to their buckets.

1. POST /v1/bookings (idempotency key): in one transaction,   - check the hold is active, belongs to the user, and has not expired;   - insert booking (status payment_pending; hold_id is UNIQUE, so a second booking for the     same hold is impossible);   - extend the hold slightly (for example 2 minutes) to cover payment processing.2. Call the payment provider with an idempotency key derived from the booking id.3. On success (synchronously, or later via a verified webhook): in one transaction,   - UPDATE seats SET status = 'booked', booking_id = :b WHERE hold_id = :h AND status = 'held';   - booking -> confirmed; hold -> converted; write an outbox event BookingConfirmed.4. Tickets are issued and the user notified asynchronously (article 33).5. On failure: booking -> failed; the hold may be released or kept until expiry so the user can retry.

The idempotency key in step 2 matters because payment calls time out ambiguously; providers such as Stripe document idempotent requests so that a retried call returns the original result instead of charging again (Idempotent requests).

The dangerous case: the provider is slow, the hold expires, someone else takes the seats, and then the payment succeeds. Step 3's conditional update changes zero rows. Now we have money and no seats. Handle it as a saga with compensation (article 21; Microsoft's Saga guidance describes compensating transactions for steps that cannot complete (Saga pattern)):

1. Try to re-acquire the same seats (they may still be free) with the hold update.
2. If not, offer equivalent seats if the user opted in, or
3. Refund automatically (idempotently, keyed by booking), mark the booking refunded, and notify the user honestly.

Extending the hold at payment start (step 1) makes this case rare; designing for it makes it harmless.

No amount of database tuning lets 50,000 hold attempts per second on a few thousand rows be pleasant. Shape the traffic instead:

Users --> CDN (static event page, cached) --> Waiting room service            each user gets a signed queue token with a position (arrival order, randomised            slightly within the first seconds before opening to reduce refresh racing)          --> admitted at a controlled rate (for example 2,000 users/minute)          --> Booking API accepts requests only with a valid "admitted" token

• The waiting room is a queue in front of the inventory, a form of queue-based load leveling (Queue-Based Load Leveling): admitted users get a fast, reliable experience; waiting users see their position.
• The admission rate is set from what the inventory service handles comfortably and from how fast seats actually sell, and adjusted live.
• Waiting-room state is simple and highly scalable (a counter and signed tokens), and can be served largely from the edge.

• Partition by event: a big event's inventory lives on its own database primary (or shard), so it does not affect other events, with a synchronous standby for failover.
• Seat maps are read far more often than they change. Serve them from a cache refreshed every second or two (or pushed over a real-time channel to admitted users). They are advisory: the hold is the authority, and a 409 response tells the client which seats were taken so it can refresh.
• General admission buckets: split each section's quantity across several bucket rows (for example 10), and pick a bucket at random; this removes the single hot row (article 14). A hold that finds its bucket empty tries others.
• Best-available allocation: offering "4 best available seats in Section B" and choosing seats server-side (from an in-memory index of free seats per section, verified by the conditional update) spreads contention better than letting everyone pick the same seats.
• Very large on-sales can route all hold requests for one event through a single-writer allocator process (holding the event's free-seat index in memory, persisting each allocation), which serialises allocation without database lock contention. That trades simplicity for throughput; use it only if measurements show the database is the bottleneck.

REQUEST PATH (on-sale)Users -> CDN (event page) -> Waiting room (signed tokens, admission rate)      -> Booking API (admitted only; per-user limits; bot checks)           -> Inventory DB for this event (primary + sync standby): atomic holds and confirmations           -> Seat-map cache (refreshed every 1-2 s)           -> Payment provider (idempotent), webhooks -> Booking APIASYNC PATHHold expiry job (scheduler, every minute) -> releases expired holdsOutbox -> BookingConfirmed -> ticket issuing, notifications, analyticsReconciliation job -> payments without bookings -> re-acquire or refund

• Seat allocation: strongly consistent, on one primary per event, enforced by conditional updates and constraints. The invariant "booked seats never exceed capacity, and each seat has at most one booking" holds by construction; a background check can verify it continuously.
• Seat maps: eventually consistent (seconds).
• Payment and booking: eventually consistent through the saga, with every intermediate state visible (payment_pending) rather than hidden.
• Read-your-writes: a user's own holds and bookings are read from the primary.

• Bots and scalpers are the main abuse: OWASP lists unrestricted access to sensitive business flows (such as buying all tickets) as an API risk (OWASP API Security Top 10 2023). Defences: per-account and per-payment-method ticket limits, CAPTCHA or proof-of-work at the waiting room, device and behaviour signals, verified accounts for high-demand events, and named tickets checked at entry.
• Signed waiting-room tokens with short validity, bound to the user, so positions cannot be forged or shared.
• Payments through the provider's tokens; no card data stored (article 28).
• Tickets as signed, unguessable codes (for example QR codes containing a signed booking reference), validated at the gate, with protection against reuse.
• Authorisation: users can see and cancel only their own holds and bookings.

"The non-negotiable requirement is that a seat is never sold twice, under on-sale bursts of about 50,000 hold attempts a second for 50,000 seats.

Each event's inventory lives on one primary database with a synchronous standby. A hold is a single transaction with a conditional update that claims every requested seat only if it is free or its hold has expired; if fewer rows change than requested, it rolls back and returns 409. General admission uses bucketed counters with conditional decrements and a non-negative check. Holds last 10 minutes; expiry is enforced on every read and cleaned up by a scheduled job.

Booking is idempotent: one booking per hold, then an idempotent call to the payment provider. On success we mark the seats booked with a conditional update on the hold; if the hold expired and the seats were taken, a saga re-acquires seats or refunds automatically. Big on-sales go through a virtual waiting room that admits users at a rate the inventory can serve, with per-account limits and bot defences. Seat maps are cached for a second or two and are advisory; the hold is the authority."

• Next: Design a Payment System: Idempotency, Ledgers and Reconciliation, which goes inside the payment step used here.
• Later: the flash sale in Design an E-Commerce System reuses the waiting room and bucketed inventory.