Ticketing (BoxOffice Flash Sale)

"Design a ticketing platform like Ticketmaster. A stadium show goes on sale at 10:00: two million fans, sixty thousand seats. Nobody may get the same seat twice."

This is the flagship case of the course because it is BoxOffice itself, and because it packs into one problem the hardest ideas of the semester: a spike that is 100× the normal load and arrives in seconds, a hot, strongly consistent resource (the seats) that cannot be cached away, an external dependency (the payment provider) that is slow and occasionally down, and adversarial traffic (bots and scalpers). Most of the system is a boring read-heavy catalog; the interview is decided in the ten minutes after 10:00.

1. Clarify the requirements

Spend the first five minutes here (see the interview framework). A ticketing system can mean "a box office for a theater with 300 seats" or "the Eras Tour on-sale": the answers below change the design completely.

Functional requirements

1. Fans browse events and venues (catalog) and see the seat map with live availability.
2. A fan selects seats and gets a hold: the seats are reserved for them for a few minutes (e.g. 10 min) while they pay.
3. The fan pays through an external payment provider; on success the order is confirmed and the tickets are issued (e-mail + app).
4. Unpaid holds expire and the seats return to sale.
5. During high-demand on-sales, fans wait in a waiting room and are admitted in order.

Non-functional requirements

Out of scope (say it explicitly)

Event creation by promoters, dynamic pricing, resale marketplace, physical ticket scanning at the gate, refunds. Mention them in one sentence and move on.

2. Back-of-the-envelope estimates

The numbers are what make this problem interesting: the total work is tiny (60 k seats fit in a few megabytes), but the peak is brutal. State the assumptions, then compute. The block below is the estimate as code — open the Source tab, change an assumption and redo it on paper.

# BoxOffice flash sale: assumptions (illustrative, change them freely)
fans        = 2_000_000   # fans who show up for the on-sale
arrival_s   = 120         # most of them arrive within ~2 min of 10:00
seats       = 60_000
per_order   = 2           # tickets per order (average)
checkout_s  = 300         # time an admitted fan spends choosing + paying
active_cap  = 10_000      # shoppers the inventory + payment path can serve at once
conversion  = 0.6         # admitted fans who end up buying
poll_s      = 10          # waiting-room status refresh interval
page_kb     = 100         # waiting-room page + assets
psp_s       = 2.0         # payment provider latency

orders       = seats / per_order
join_rate    = fans / arrival_s                 # joins per second at the door
no_queue_rps = fans * 5 / 60                    # 5 requests/fan in the 1st minute, no queue
naive_poll   = fans / poll_s                    # status polls if all hit the origin
admit_rate   = active_cap / checkout_s          # Little's Law: L = λ·W  →  λ = L / W
admits       = orders / conversion
sellout_min  = admits / admit_rate / 60
order_rate   = admit_rate * conversion
pay_inflight = order_rate * psp_s               # Little's Law again
seat_map_rps = active_cap / 3                   # each shopper refreshes the map every 3 s
edge_gb      = fans * page_kb / 1e6
inventory_mb = seats * 100 / 1e6                # ~100 B per seat row

rows = [
    ("orders", orders, ""), ("join_rate", join_rate, "req/s"),
    ("no_queue_rps", no_queue_rps, "req/s"), ("naive_poll", naive_poll, "req/s"),
    ("admit_rate", admit_rate, "fans/s"), ("admits", admits, "fans"),
    ("sellout_min", sellout_min, "min"), ("order_rate", order_rate, "orders/s"),
    ("pay_inflight", pay_inflight, "calls"), ("seat_map_rps", seat_map_rps, "req/s"),
    ("edge_gb", edge_gb, "GB"), ("inventory_mb", inventory_mb, "MB"),
]
print("| quantity | value | unit |\n|---|---:|---|")
for name, value, unit in rows:
    v = f"{value:,.0f}" if abs(value) >= 100 else f"{value:,.2f}"
    print(f"| `{name}` | {v} | {unit} |")

What the numbers tell us — this paragraph is the part the interviewer is listening for:

• Without a waiting room the inventory would see ~170 k requests/s for a minute. A single PostgreSQL primary does a few thousand small write transactions per second; no amount of app servers fixes that, because the bottleneck is a handful of hot rows. ⇒ we need admission control.
• With 10 k concurrent shoppers and 5 minutes each, Little's Law gives an admission rate of ~33 fans/s (2 000/min), a sell-out in ~25 minutes and only ~20 orders/s — easy for one well-indexed database.
• The waiting room itself must take ~17 k joins/s and, if everybody polls the origin, 200 k polls/s. ⇒ serve the page from the CDN and make the status endpoint cheap (a signed token + a single counter read, cacheable for a second).
• About 40 payment calls are in flight at any time (20/s × 2 s). ⇒ size the connection pool and bulkhead of the payment adapter for that, not for the 2 M fans.
• The entire inventory is ~6 MB: storage is not a problem; contention is.

3. API

Keep it short and resource-oriented; the interesting fields are the tokens and the idempotency key.

POST /v1/events/{eventId}/queue                      → 201 {queueToken, position, etaSeconds}
GET  /v1/queue/{queueToken}                          → 200 {status: WAITING|ADMITTED, position, accessToken?}

GET  /v1/events/{eventId}                            → 200 event, venue, price levels   (CDN, minutes)
GET  /v1/events/{eventId}/availability?section=A     → 200 {seatsBitmap, version}      (cache, 1 s)

POST /v1/events/{eventId}/holds                      → 201 {holdId, seats, expiresAt} | 409 SEAT_TAKEN
     Authorization: Bearer <accessToken>
     Idempotency-Key: 7f3c…
     {"seatIds": ["A-12-07", "A-12-08"]}
DELETE /v1/holds/{holdId}                            → 204

POST /v1/orders                                      → 202 {orderId, status: PENDING_PAYMENT, paymentUrl}
     Idempotency-Key: 9a41…
     {"holdId": "…"}
GET  /v1/orders/{orderId}                            → 200 {status: CONFIRMED|PENDING_PAYMENT|EXPIRED|FAILED}

POST /v1/webhooks/payments                           ← provider callback, signed (HMAC)

• The accessToken is what the waiting room hands out: a short-lived signed token (e.g. a JWT with eventId, userId, exp = 15 min). The gateway rejects hold/order calls without a valid one, so nobody can skip the queue by calling the API directly.
• Idempotency-Key on holds and orders: mobile networks retry, users double-click; the server stores the key with the response and replays it instead of creating a second hold or order.
• POST /v1/orders returns 202 Accepted: payment is asynchronous; the client polls the order (or gets a push) until it is CONFIRMED.

4. Data model

The inventory is small, relational and needs transactions ⇒ SQL (PostgreSQL), partitioned by event_id if there are many events. The catalog is read-mostly and can live in the same database behind a cache, or in a document store.

CREATE TABLE seat (
    event_id     BIGINT      NOT NULL,
    seat_id      TEXT        NOT NULL,             -- 'A-12-07' (section-row-number)
    section      TEXT        NOT NULL,
    price_cents  INT         NOT NULL,
    status       TEXT        NOT NULL DEFAULT 'AVAILABLE',  -- AVAILABLE | HELD | SOLD
    hold_id      UUID,
    held_until   TIMESTAMPTZ,
    version      INT         NOT NULL DEFAULT 0,
    PRIMARY KEY (event_id, seat_id)
);

CREATE TABLE hold (
    hold_id      UUID PRIMARY KEY,
    event_id     BIGINT      NOT NULL,
    user_id      BIGINT      NOT NULL,
    expires_at   TIMESTAMPTZ NOT NULL,
    status       TEXT        NOT NULL               -- ACTIVE | CONVERTED | EXPIRED | RELEASED
);

CREATE TABLE ticket_order (
    order_id        UUID PRIMARY KEY,
    hold_id         UUID UNIQUE NOT NULL,           -- one order per hold
    user_id         BIGINT NOT NULL,
    total_cents     INT    NOT NULL,
    status          TEXT   NOT NULL,                -- PENDING_PAYMENT | CONFIRMED | FAILED | EXPIRED
    payment_ref     TEXT,                           -- provider's id
    idempotency_key TEXT UNIQUE NOT NULL,
    created_at      TIMESTAMPTZ NOT NULL DEFAULT now()
);

CREATE TABLE outbox (                               -- transactional outbox → Kafka
    id BIGSERIAL PRIMARY KEY, topic TEXT, payload JSONB, created_at TIMESTAMPTZ DEFAULT now()
);

5. High-level design

Read the diagram as two paths. The cheap path (catalog, waiting page, availability) is served by the CDN and caches and never touches the hot rows. The expensive path (hold → order → payment) is protected by the waiting room, which lets in only what the database and the payment provider can take.

flowchart LR
    fan([Fan / mobile]) --> cdn["CDN<br/>event pages, waiting page"]
    cdn --> waf["WAF<br/>bots, DDoS"]
    waf --> gw["API Gateway<br/>auth, rate limit,<br/>access token check"]
    gw --> wr["Waiting room"]
    wr --> q[("Queue<br/>Redis sorted set")]
    gw --> cat["catalog"]
    cat --> cache[("Cache<br/>availability 1 s")]
    gw --> inv["inventory<br/>holds"]
    inv --> sql[("PostgreSQL<br/>seat, hold, order")]
    gw --> ord["order"]
    ord --> sql
    ord --> pay["payment adapter"]
    pay --> psp[["Payment provider"]]
    psp -. webhook .-> pay
    sql -. outbox .-> kafka[["Kafka<br/>order events"]]
    kafka --> notif["notification"] --> email[["E-mail / push"]]
    kafka --> an["analytics"]
    sched["scheduler<br/>expire holds"] --> sql

The happy path of one fan, step by step:

sequenceDiagram
    autonumber
    participant F as Fan
    participant W as Waiting room
    participant I as inventory
    participant O as order
    participant P as Payment provider
    participant N as notification
    F->>W: join (10:00:03)
    W-->>F: queueToken, position 48 210
    F->>W: poll status (every 10 s, cached)
    W-->>F: ADMITTED + accessToken (15 min)
    F->>I: POST /holds {A-12-07, A-12-08} + accessToken
    I->>I: conditional UPDATE (both seats or none)
    I-->>F: 201 holdId, expiresAt = now + 10 min
    F->>O: POST /orders {holdId} + Idempotency-Key
    O->>P: create payment (idempotency key = orderId)
    O-->>F: 202 PENDING_PAYMENT, paymentUrl
    P-->>O: webhook: payment succeeded
    O->>O: seats SOLD, order CONFIRMED, outbox row (one transaction)
    O-)N: OrderConfirmed (Kafka)
    N-->>F: e-mail + push with tickets

6. Deep dives

The interviewer will pick one or two of these. Lead with the one that protects correctness (holds), then the one that protects availability (the waiting room).

6.1 Seat holds without double booking

Two fans click seat A-12-07 in the same millisecond. Exactly one must win. There are four classic ways to guarantee it (transactions & isolation):

BEGIN;
UPDATE seat
   SET status = 'HELD', hold_id = $1, held_until = now() + interval '10 minutes',
       version = version + 1
 WHERE event_id = $2
   AND seat_id = ANY($3)
   AND (status = 'AVAILABLE' OR (status = 'HELD' AND held_until < now()));
-- the app checks: rows updated == number of seats requested, otherwise ROLLBACK → 409
INSERT INTO hold (hold_id, event_id, user_id, expires_at, status)
     VALUES ($1, $2, $4, now() + interval '10 minutes', 'ACTIVE');
COMMIT;

BEGIN;
SELECT seat_id, status, held_until FROM seat
 WHERE event_id = $1 AND seat_id = ANY($2)
 ORDER BY seat_id
   FOR UPDATE;            -- NOWAIT or SKIP LOCKED for "best available"
-- app checks every row is free, then UPDATE ... ; COMMIT

UPDATE seat SET status = 'HELD', hold_id = $1, version = version + 1
 WHERE event_id = $2 AND seat_id = $3 AND version = $4;   -- 0 rows → somebody won, retry

SET hold:42:A-12-07 3f9a... NX EX 600   →  OK  (you got it)  |  nil (taken)

Expiration. A hold must end even if the fan closes the browser. Combine (a) lazy expiration in the hold statement (an expired HELD seat counts as available), (b) a scheduler job that sweeps hold rows with expires_at < now() every few seconds and flips seats back to AVAILABLE so the seat map is accurate, and (c) extending the hold while a payment is in flight, so a fan who is paying does not lose the seat at second 601.

6.2 The waiting room (virtual queue)

The waiting room is load shedding with good manners: instead of letting 2 M requests hit the inventory and fail randomly, it turns the burst into a steady, measured flow and tells each fan where they stand.

flowchart LR
    j["Fans join<br/>~17 k/s"] --> rq[("Queue<br/>sorted by<br/>random or arrival")]
    rq --> d{"Admitter<br/>every second"}
    d -->|"admit λ = L / W<br/>≈ 33 fans/s"| tok["accessToken<br/>(signed, 15 min)"]
    tok --> shop["Shopping<br/>≤ 10 k at once"]
    shop -->|"buys or times out"| out([leaves])
    out -. frees a slot .-> d

Design points:

1. Static page on the CDN. The waiting page is HTML + JS cached at the edge; the only dynamic call is the status poll, answered from Redis (ZRANK for the position) or from a cached "now serving number" — the client compares it with its own number, so the origin answers one value for everybody.
2. Admission rate from Little's Law. The admitter lets in λ = L / W fans per second, where L is the number of shoppers the checkout path can serve (measured in the load test, e.g. 10 k) and W the time each spends (5 min). It is a closed loop: admit more when shoppers leave early, admit fewer when p99 of POST /holds rises or the payment provider slows down.
3. Fairness. Pure FIFO rewards whoever has the fastest connection — usually bots. A common policy: everyone who arrives before 10:00 gets a random position at 10:00 (a lottery), and late arrivals go to the back in FIFO order.
4. Tokens, not sessions. Admission produces a signed accessToken (event, user, expiry). The gateway verifies the signature locally — no shared session store on the hot path — and enforces "max 6 tickets per account".
5. Bots. The WAF does bot scoring, rate limits per IP/ASN and challenges; requiring a logged-in, verified account to join is the strongest filter. Queue-it, Cloudflare Waiting Room and the AWS Virtual Waiting Room solution are real products built on these ideas.

6.3 Checkout and payment: a state machine, not a function call

A payment provider answers in seconds, times out, and sometimes calls you back before your HTTP request returns. Model the order as a state machine whose transitions are idempotent (integrations, payment system case).

stateDiagram-v2
    [*] --> HELD: POST /holds
    HELD --> PENDING_PAYMENT: POST /orders (extend hold)
    HELD --> EXPIRED: TTL (10 min) elapses
    PENDING_PAYMENT --> CONFIRMED: webhook succeeded
    PENDING_PAYMENT --> FAILED: webhook failed / declined
    PENDING_PAYMENT --> CONFIRMED: reconciliation finds payment
    FAILED --> HELD: retry with another card (hold still valid)
    EXPIRED --> [*]
    CONFIRMED --> [*]

• Idempotency key to the provider = orderId. If the adapter times out and retries, the provider returns the same payment instead of charging twice.
• Webhooks are the source of truth for the outcome; they are signed (HMAC), may arrive twice or out of order, so the handler is UPDATE ticket_order SET status='CONFIRMED' WHERE order_id=$1 AND status='PENDING_PAYMENT' — a second delivery changes nothing.
• Confirm in one transaction: seats HELD → SOLD, order CONFIRMED, an outbox row. A relay publishes the outbox to Kafka; notification consumes it idempotently (dedupe by orderId) and sends the e-mail (messaging patterns).
• Reconciliation. A scheduler job lists PENDING_PAYMENT orders older than N minutes and asks the provider for their status. This fixes lost webhooks — and the nasty case "payment succeeded after the hold expired": either the seats are still free (confirm) or they were resold (refund automatically and apologize).
• Resilience. Timeout + circuit breaker + bulkhead around the provider (reliability patterns); if the breaker is open, stop admitting new fans instead of letting them hold seats they cannot pay for.

6.4 The read path: seat map and catalog

Fans hammer the seat map. Serving it from the seat table would put reads on the same hot rows as the holds.

• Keep a per-section availability bitmap (one bit per seat — 60 k seats = 7.5 kB) in the cache, rebuilt every second from the database or updated from hold/sold events. Clients poll it (or receive it via SSE) with a version number.
• Accept staleness: the map may show a seat as free that was taken 800 ms ago. The hold request is the real check; return 409 SEAT_TAKEN with the fresh bitmap so the UI updates.
• Pre-warm the CDN and the cache before 10:00 (event page, images, bitmaps): a cold cache at the moment of the spike is a self-inflicted stampede (caching failure modes).
• Offer "best available": the server picks seats with FOR UPDATE SKIP LOCKED, so concurrent buyers never wait on each other's rows.

7. Bottlenecks, failure modes and trade-offs

The two trade-offs to say out loud: consistency over availability for the inventory (if the database is unreachable, stop selling; never sell from a stale replica), and fairness and stability over raw speed (a sale that takes 25 orderly minutes beats one that crashes at minute 2).

8. Try it in the playground

The flash-sale scenario replays the spike when the sale opens (our 10:00) on a design that starts without a waiting room: users → lb → app → inventory-db, with buyers calling the payment provider (quota 500 req/s). Its load profile already contains the spike — a scripted event multiplies the traffic by 20 at t = 60 s for 90 s.

Open the full playground

9. Follow-up questions an interviewer asks

10. Self-assessment rubric

Related: Hands-on 6 (seat holds and transactions), Hands-on 7 (outbox and waiting-room queue), Hands-on 9 (resilience around payment), team project.

How it connects

Which classes does this case test? Each branch is a class whose ideas the design relies on (blue), with the palette components where they show up (green):

flowchart LR
    CASE(["Ticketing (BoxOffice)"]) --> PERF["Performance<br/>Little's Law admission, spike test"]:::tech
    CASE --> EDG["Edge<br/>CDN, WAF, waiting room"]:::tech
    CASE --> DB["Databases<br/>seat holds: locks, conditional updates"]:::tech
    CASE --> CAC["Caching<br/>availability cached for 1 s"]:::tech
    CASE --> CMP["Compute<br/>checkout state machine, payment adapter"]:::tech
    CASE --> MSG["Messaging<br/>outbox, order events"]:::tech
    CASE --> REL["Reliability<br/>timeouts, retries, admission control"]:::tech
    EDG -.-> k1["cdn · waf · apigw · queue"]:::comp
    DB -.-> k2["sql · scheduler"]:::comp
    CAC -.-> k3["cache"]:::comp
    CMP -.-> k4["payment"]:::comp
    MSG -.-> k5["kafka · notifications · analytics"]:::comp
    classDef comp fill:#1e9e5a22,stroke:#1e9e5a
    classDef tech fill:#2f6fed22,stroke:#2f6fed

Classes it tests: Edge (WAF, bots, waiting room) · Databases — transactions · Caching — failure modes · Compute — integrations · Messaging — patterns · Reliability — patterns · Performance — capacity planning · Hands-on 6, 7 and 9. Palette components: cdn · waf · apigw · queue · sql · cache · kafka · scheduler · payment · notifications · analytics. Scenarios: flash-sale.

References

• XU, A.; LAM, S. System Design Interview — An Insider's Guide, vol. 2, ch. 7 "Hotel Reservation System" (holds, concurrency, idempotency)¹.
• KLEPPMANN, M.; RICCOMINI, C. Designing Data-Intensive Applications, 2nd ed., chapter on transactions (lost updates, write skew, SELECT … FOR UPDATE)².
• Idempotent APIs and keys as used by payment providers³.
• Load shedding and overload handling⁴.