Design a Ticket Booking & Flash-Sale System
like Ticketmaster

"Design Ticketmaster" looks like a booking-system question, and candidates who treat it as one — CRUD an event, CRUD a seat, CRUD an order — miss the point entirely. The hard problem only shows up at one specific moment: the instant a high-demand show goes on sale, when a fixed, tiny inventory (a 50,000-seat arena) is hit by a burst of concurrent demand forty times larger (2,000,000+ people refreshing at once). For 99% of the calendar year this system looks like a boring read-heavy catalog. For the ten minutes that matter, it's a write problem with forty claimants for every seat.

This is a fundamentally different regime from most "design a booking system" interviews. Airbnb-style booking deals with low contention across huge inventory: 150 million distinct listings, and any two guests booking at the same instant are almost certainly booking different properties. The hard problems there are search freshness and geo-partitioning. Ticketmaster is the opposite regime: extreme contention on a tiny, single inventory — every one of those 2 million people is trying to write to the same few thousand rows in the same few seconds. Search and catalog design barely matter here; write arbitration is everything. If you find yourself reaching for Airbnb's playbook (shard by listing, decouple a search index), stop — there is effectively one "listing" and sharding it doesn't dissolve the contention, it just moves it.

The rate limiter design post covers the token-bucket and sliding-window mechanics this article's virtual waiting room borrows wholesale for admission pacing (§8) — read that post for the algorithm, this one for how it's repurposed as a fairness queue rather than an abuse shield. And where Airbnb-style booking solves "don't double-book one of 150 million distinct listings," this post solves "don't oversell one of 50,000 seats when 2 million people want them in the same second" — same-shaped booking flow, opposite contention regime, different solution at every layer.

Functional requirements

Non-functional requirements

NFR reasoning

This is a contention-bound system. The dimensions that matter are how many writers contend for the same tiny set of keys, and for how long; request volume and storage barely register. Two numbers set the shape of everything downstream: the size of the inventory (small — tens of thousands of rows) and the ratio of demand to that inventory (huge — tens of buyers per seat).

Numbers to know

The SLOs in §2 are stated in time, so it's worth being explicit about what each relevant latency number costs, and which decision it settles.

Latency: the numbers that set the budget

Contention: the numbers that shape the design

The architecture separates into four concerns that have almost nothing in common operationally: browsing (cold, read-heavy, ordinary), admission (the thundering-herd gate), seat contention (extreme write throughput, no durability requirement of its own), and commit (low throughput, strict durability requirement). Routing them to separate services lets each be provisioned for what it needs, instead of one service straining to be both very fast and very safe at once.

Component breakdown

API Gateway terminates TLS, authenticates requests, and routes to the right service. It also enforces a first line of pacing — a standard per-IP/per-account rate limit (see rate limiter design) that catches naive scripted traffic before it even reaches the waiting room.

Catalog Service serves event browsing and the seat-map view from read replicas. It's an ordinary read-heavy service, kept separate so it never competes for capacity with the contention path. The seat map's free/held/sold overlay is the one live part; §8 covers how it stays fresh without reading Seat Redis per viewer.

Waiting Room is the admission gate for high-demand events. A buyer without a valid admission token is placed in a queue; the service admits buyers in controlled batches and issues each a short-lived, signed token. It also runs the first bot-defense checks (§10b) before a token is ever issued.

Seat Hold Service is the contention gate. It accepts a seat-hold request only from a caller presenting a valid admission token, and arbitrates concurrent claims using one atomic Redis script that claims all the requested seats or none (§5). It never talks to Postgres: holds, winners' included, live only in Redis until checkout.

Checkout Service owns the correctness-critical commit: it converts a hold into a paid order. It verifies the hold in Seat Redis, authorizes payment with the external gateway, inserts the sale into the Order DB — the commit point — and only then captures the payment (§6). If the insert loses, it voids the authorization and the buyer is never charged.

Admission Redis holds queue position and issued tokens. It's disposable in the sense that losing it degrades admission fairness, not correctness — nothing here is load-bearing for the zero-oversell guarantee.

Seat Redis holds the live state of every seat: free (no key), held (a key with the holder, the quoted price and a TTL), or sold (a key with no TTL). It's the system's highest-throughput store and the only place a hold exists — and, like Admission Redis, an arbitration layer rather than the source of truth. If it's lost, its sold keys are rebuilt from the Order DB (§10).

Order DB (Postgres) is the one component that must not lose a committed write: the durable ledger where the zero-oversell guarantee lives, as a primary key on (event_id, seat_id) in the sold_seats table (§7) that rejects a second sale of any seat. It replicates synchronously so a failover can't drop a sale (§2's RPO = 0). It sees only completed sales; every component in front of it exists to keep it that way.

Kafka carries order events out of the checkout transaction via the outbox pattern (see the equivalent pattern in Airbnb-style booking design): the Checkout Service writes an outbox row in the same transaction as the order commit, and a connector publishes it. Ticket-confirmation notifications and the dynamic-pricing demand signal both consume this stream independently, without adding latency to checkout.

Architectural rationale

Real-world comparison

Once a buyer is admitted and looking at the seat map, claiming a seat comes down to one question: when several admitted buyers try to hold the same seat within milliseconds of each other, how does exactly one of them win? There are two classic answers — lock first, or check at commit — and this system uses both, at different layers.

Our choice for this system: both, at different layers. The hold step (§4's Seat Hold Service) takes a pessimistic lock in Redis, because at a 40:1 contention ratio, letting every claimant proceed optimistically means 39 of every 40 buyers pick seats, enter payment details, and only then learn they lost — a worse experience than being told "that seat's gone" in the ~0.3 ms it takes Redis to refuse a SET … NX. The lock is a performance layer, not the guarantee: it lives in Redis, which can fail over and lose recent writes (§10). The guarantee is the commit in §6, an optimistic check in its simplest form — an INSERT into sold_seats, whose primary key on (event_id, seat_id) rejects a second sale of a seat however the two buyers got there. If Redis ever let two buyers hold the same seat, both reach checkout and exactly one insert succeeds; the other buyer's payment authorization is voided, so they're never charged (§6). This is the same "hot-path lock, durable-path constraint" split Airbnb-style booking uses; the difference here is how aggressively the hot path has to turn losers away, because the contention ratio is orders of magnitude higher.

-- Step 1: Redis Lua script — all-or-nothing hold (Seat Hold Service)
-- KEYS[1]    = "hold:{event_id}:<hold_id>"
-- KEYS[2..n] = "seat:{event_id}:<seat_id>", one per requested seat
--              (the {event_id} hash tag keeps every key in one slot, §9)
-- ARGV[1] = hold_id (derived from the request's idempotency key, so a retry reuses it)
-- ARGV[2] = buyer_id   ARGV[3] = price quote, cents   ARGV[4] = ttl_ms (480000)
for i = 2, #KEYS do
  local v = redis.call('get', KEYS[i])
  if v and v ~= ARGV[1] then
    return {'TAKEN', KEYS[i]}  -- another buyer's hold, or SOLD: claim nothing
  end
end
for i = 2, #KEYS do
  -- NX: a retry of this same hold claims nothing new and never extends the TTL
  redis.call('set', KEYS[i], ARGV[1], 'NX', 'PX', ARGV[4])
end
redis.call('hset', KEYS[1], 'buyer', ARGV[2], 'price', ARGV[3])
redis.call('pexpire', KEYS[1], ARGV[4], 'NX')  -- PEXPIRE NX: Redis 7+
return {'HELD'}

-- Step 2: Checkout Service. First: the hold key exists, its buyer matches, every
-- seat key still carries this hold_id, and payment is AUTHORIZED (not captured)
-- for the quoted price. Then one transaction — the commit point:
BEGIN;
INSERT INTO orders (order_id, event_id, buyer_id, total_cents,
                    payment_auth_id, idempotency_key, status)
VALUES ($order_id, $event_id, $buyer_id, $total, $auth_id, $idem_key, 'pending_capture');
INSERT INTO sold_seats (event_id, seat_id, order_id, price_paid_cents)
VALUES ($event_id, $seat_1, $order_id, $p1),
       ($event_id, $seat_2, $order_id, $p2);  -- one row per held seat
INSERT INTO outbox (aggregate_id, event_type, payload)
VALUES ($order_id, 'order_committed', $payload);
COMMIT;
-- unique_violation on sold_seats_pkey → ROLLBACK, void the authorization, 409.
--   The seat was already sold to someone else; this buyer is never charged.

-- Step 3: capture the authorization → UPDATE orders SET status = 'captured'.
-- Step 4: SET seat:{event_id}:<seat_id> "SOLD:<order_id>" per seat (no TTL),
--         then DEL hold:{event_id}:<hold_id>.

The admission token shapes this API. It's a capability rather than a lookup: the one endpoint the herd would otherwise flatten, /seats/hold, requires it, and it has to be verifiable without a network call back to the service that issued it (§4's rationale for why).

POST /waiting-room/join

Called when a buyer navigates to a high-demand event that has admission control active. Returns a queue position immediately and a client-side polling interval; no token yet. The queue position is keyed by a deterministic id derived from device and account, not allocated fresh per request, so a retried join after a timeout returns the buyer's existing queue_id instead of allocating a second position — the same double-click problem §10 solves for seat holds, but here it protects queue fairness rather than inventory.

// Request
{ "event_id": "EVT-88213", "captcha_token": "03AGdBq..." }

// Response 200 OK
{
  "queue_id": "Q-9f21ab",
  "position": 483211,
  "estimated_wait_s": 240,
  "poll_after_ms": 3000
}

GET /waiting-room/status?queue_id=…

Polled at the client-supplied interval (jittered client-side to avoid every client synchronising into a new thundering herd). Once admitted, this response carries the admission token — a short-lived, signed JWT the client attaches to every subsequent request as a bearer token. Signing means the Seat Hold Service can validate it locally, with no call back to the Waiting Room.

// Response 200 OK — still queued
{ "status": "queued", "position": 12044, "poll_after_ms": 3000 }

// Response 200 OK — admitted
{
  "status": "admitted",
  "admission_token": "eyJhbGciOi...",  // JWT, exp: now + 10 min
  "expires_at": "2026-09-17T19:32:00Z"
}

POST /seats/hold

Authorization: Bearer <admission_token> is required and validated by signature + expiry only — no database lookup. The request names specific seats or asks for a quantity of "best available" seats in a section, which the service resolves against Seat Redis (§9). Either way the seats are held all-or-nothing: a two-seat request that finds one seat taken holds neither, so no buyer is left with half a pair. Requests carry an Idempotency-Key, from which the hold_id is derived, so a retried request returns the existing hold rather than competing with it.

// Request
{ "event_id": "EVT-88213", "seat_ids": ["SEC-A-ROW-3-12", "SEC-A-ROW-3-13"] }
// or: { "event_id": "EVT-88213", "best_available": { "quantity": 2, "section": "floor" } }

// Response 201 Created
{
  "hold_id": "H-771029",
  "seat_ids": ["SEC-A-ROW-3-12", "SEC-A-ROW-3-13"],
  "price_quote": 378.00,  // stored in the hold record, locked for its duration (§5)
  "expires_at": "2026-09-17T19:40:00Z"
}

// Response 409 Conflict — lost the race; nothing was held
{ "error": "seat_unavailable", "message": "One of those seats was just claimed." }

POST /checkout

Authorized by the buyer's ordinary session plus ownership of the hold — not the admission token. Once a buyer holds seats, the hold is the capability, so a token that expires mid-checkout can't strand a buyer still inside their 8-minute hold. Requires an Idempotency-Key header: mobile clients retry on timeouts, and a retried request must never authorize or capture twice. The price charged is the price_quote stored with the hold, not whatever the dynamic-pricing service shows now, so a price change mid-checkout never surprises a buyer.

// Request — Idempotency-Key header required
{ "hold_id": "H-771029", "payment_method_id": "pm_3x91..." }

// Response 201 Created
{
  "order_id": "ORD-55123",
  "status": "confirmed",
  "seat_ids": ["SEC-A-ROW-3-12", "SEC-A-ROW-3-13"],
  "total_charged": 378.00
}

// Response 409 Conflict — lost at the commit (§6); authorization voided
{ "error": "seat_sold", "message": "That seat sold to another buyer. Your card was not charged." }

// Response 410 Gone — hold expired before checkout completed
{ "error": "hold_expired", "message": "Your hold on this seat has expired." }

Optional endpoints by level

The dominant path through an on-sale spike, with the three branch points that matter for correctness: losing the hold race, letting a hold expire, and losing at the commit.

The order — authorize, commit, capture — keeps refunds out of the conflict path. Capturing first would mean every buyer who loses at step 7 has been charged and must be refunded, which takes days to reach their statement. Committing before any payment step would sell seats to cards that then decline. Authorizing first reserves the funds without moving them — a card authorization typically lasts about seven days, far longer than an 8-minute hold — so a lost commit ends in a void and a won commit is guaranteed to be payable. The one remaining gap is a capture that fails after the commit, which is rare because the funds are already reserved; the order waits in pending_capture for a retry sweep (§10).

Three things are stored durably: what each seat is, which seats are sold, and the orders that bought them. Holds are deliberately absent — they live only in Seat Redis (§5). Access patterns first, since they force the schema below.

Two observations force the schema. First, the only hot-path write is the commit: a point insert keyed on (event_id, seat_id), with no range scan or join, which is what makes the primary-key guarantee cheap to enforce. Second, neither the seat-map read nor the hold burst touches Postgres, so this database is provisioned for completed sales rather than for the 6,000-attempts-a-second burst in front of them.

Sale state needs a companion table for the seat's identity — which section, row and seat number a given seat_id refers to, and its base price tier — versus its fast-moving state. The catalog is reference data, written once when an event is set up and effectively read-only afterward; it's what §4's Catalog Service loads to seed Seat Redis and render the seat map, and what a hold request's seat_id is validated against before it's even worth attempting a lock.

-- Reference data: what a seat IS, seeded once when the event is set up
CREATE TABLE event_seats (
  event_id    BIGINT      NOT NULL,
  seat_id     TEXT        NOT NULL,       -- e.g. 'SEC-A-ROW-3-12'
  section     TEXT        NOT NULL,
  row_label   TEXT        NOT NULL,
  seat_number INT         NOT NULL,
  price_tier  TEXT        NOT NULL,
  map_x       NUMERIC,                     -- seat-map render coordinates
  map_y       NUMERIC,
  PRIMARY KEY (event_id, seat_id)
);

CREATE TABLE orders (
  order_id        BIGINT      PRIMARY KEY,
  buyer_id        BIGINT      NOT NULL,
  event_id        BIGINT      NOT NULL,
  total_cents     INT         NOT NULL,
  payment_auth_id TEXT        NOT NULL,  -- gateway authorization, captured after commit
  idempotency_key TEXT        NOT NULL UNIQUE,
  status          TEXT        NOT NULL,  -- 'pending_capture' | 'captured' | 'cancelled'
  created_at      TIMESTAMPTZ NOT NULL DEFAULT now()
);
CREATE INDEX idx_orders_buyer ON orders (buyer_id, created_at DESC);
CREATE INDEX idx_orders_pending ON orders (created_at) WHERE status = 'pending_capture';

-- Source of truth for the zero-oversell guarantee: one row per sold seat
CREATE TABLE sold_seats (
  event_id         BIGINT      NOT NULL,
  seat_id          TEXT        NOT NULL,
  order_id         BIGINT      NOT NULL REFERENCES orders,
  price_paid_cents INT         NOT NULL,  -- the hold's quote, not today's price
  sold_at          TIMESTAMPTZ NOT NULL DEFAULT now(),
  PRIMARY KEY (event_id, seat_id),       -- the structural guarantee
  FOREIGN KEY (event_id, seat_id) REFERENCES event_seats
);

CREATE TABLE outbox (
  id           BIGINT      PRIMARY KEY GENERATED ALWAYS AS IDENTITY,
  aggregate_id BIGINT      NOT NULL,   -- order_id
  event_type   TEXT        NOT NULL,   -- 'order_committed', 'order_cancelled'
  payload      JSONB       NOT NULL,
  created_at   TIMESTAMPTZ NOT NULL DEFAULT now()
);

The catalog is an ordinary cold read path, and the one hot read — the seat map — is covered at the end of this section. The main optimisation target is the write side: turning an unbounded, synchronised burst of demand into a stream every downstream component is provisioned for.

Admission pacing is a token bucket, reused

The Waiting Room's admission rate (§3, §5b) is implemented with the token-bucket mechanism from rate limiter design, keyed per event instead of per user: tokens refill at the configured admission rate, and each refill tick admits the next batch of queued buyers in strict position order. The difference from a standard rate limiter is intent — there, the bucket protects the system from abuse; here, it protects the system from its own legitimate traffic, and a full bucket means "let more people in," not "reject this request."

Why admission comes in batches

A buyer only learns they've been admitted when their client next polls, every ~3 s (§5b), so admitting continuously gains nothing over admitting in batches at that cadence. Batching every 2–5 s (§2's admission-latency NFR sets the window) turns admission into one write per batch rather than one per buyer: advance the event's admitted-up-to position by ~6,000 (2,000/s × 3 s), and each status poll compares the buyer's queue position against that single counter before issuing a token.

Admission rate: fixed from §3, with a manual override

The admission rate is set before the sale from §3's arithmetic — the rate Seat Redis and checkout are provisioned for — and operators can change it mid-sale through §5b's override endpoint while watching Seat Redis p99 and checkout error rates. At this article's numbers one Seat Redis primary runs at a small fraction of its capacity (§9), so a fixed rate with a human override is enough.

Connection pooling for the commit path

Postgres sees only commits — ~25,000 orders per sale at §3's defaults, spread over the minutes buyers take to check out. A transaction-mode connection pooler (PgBouncer) keeps the backend connection count bounded however many Checkout Service instances are running, so a cluster of simultaneous checkouts queues briefly in the pooler instead of exhausting Postgres's connection limit before its throughput.

Keeping the seat map fresh without reading Seat Redis per viewer

Every admitted buyer loads the seat map, and it goes stale the moment seats start going. Reading 50,000 keys per page view would put that load on the store that's busy arbitrating holds. Instead, a snapshotter reads each section's state from a Seat Redis replica once a second into a bitmap — one bit per seat, available or not, about 6 KB for the whole venue — served from a CDN-cacheable endpoint, with per-second deltas pushed to open pages over server-sent events. A buyer can still click a seat that went a second ago; the hold returns 409 in under a millisecond and the map repaints. The map is advisory, and the hold is the only check that counts. Clients retrying after a 409 add random jitter, so losers from the same batch don't re-collide in lockstep.

Everything contended in this system fits on one Redis primary. At §3's defaults that's 50,000 seat keys and ~6,000 hold scripts a second, each a handful of commands; one primary sustains on the order of 100,000 simple commands a second on a single core, so the hold path uses a fraction of it with room for several times §3's attempt rate. The design runs one Seat Redis primary per on-sale, plus a replica for failover, and keys every seat as seat:{event_id}:<seat_id>. The {event_id} hash tag puts all of an event's keys in one Redis Cluster slot, which is what lets a multi-seat hold script touch several seats atomically — Redis rejects a script whose keys span slots.

"Best available" runs inside that same primary as one script. Most flash-sale buyers ask for "2 tickets, best available" rather than picking a seat, and the obvious implementation — rank the seats in the service, then try to hold the top pair — sends every buyer at the same few premium seats, where all but one lose and retry. Instead, each section's free seats sit in a sorted set scored by seat quality, and the hold script pops the best N and claims them in the same atomic step, so two buyers asking at the same instant get different seats rather than colliding. A seat whose hold expires goes back into its set, driven by a second sorted set ordered by hold expiry.

The component that needs real scaling work is the waiting room, because it sees all 2,000,000 buyers rather than the admitted few thousand per second. Polling every ~3 s, the queue generates on the order of 670,000 status checks a second — by far the largest raw request volume in the system — while the seat store handles about a hundredth of that. Geo-distribution is deliberately avoided for the hot path: one event is one small, contended keyspace, and spreading it across regions would add consensus latency to every hold.

Big on-sales also overlap — a stadium tour and an arena show can open the same Friday morning. Each on-sale gets its own admission bucket and its own Seat Redis primary, provisioned ahead of time (on-sales are scheduled weeks out, so this is planning rather than autoscaling). The point is isolation: one sale's backlogged waiting room or busy Seat Redis must not slow down a second sale.

One principle runs through every row: Redis can be wrong, Postgres can't. A failure in front of the commit may cost a buyer a hold or a retry; none may produce two sales of one seat, or a charge without a seat.

The threats here are dominated by two things: this is a money-movement system (fraud, chargebacks), and it's also a scarce-resource allocation system that automated buyers have a strong financial incentive to game (scalping). Five threats, each with a headline defense: queue-stuffing bots → CAPTCHA/proof-of-work plus per-account velocity limits at admission; hold hoarding → a per-account hold cap enforced inside the hold script; admission-token theft or forgery → signed, event-scoped, short-lived tokens; payment fraud and chargebacks → idempotency keys and velocity checks before authorization; price scraping → a rate-limited price endpoint that never exposes demand signals. The reasoning and interview probes for each are in the accordions. Entry validation at the venue — rotating barcodes, scanner redemption — is a separate system with its own store, out of scope here.

The mechanisms don't change much across levels — what changes is whether they're composed into one coherent contention story or reached for independently.

Classic probes, level-differentiated answers