Design a ticket-booking service

01Define what buying a seat means

Design exact-seat booking for a show. Customers browse the catalog, view a seat map, hold up to ten selected seats, pay and recover their booking. Exclude resale, auctions and atomic carts spanning several shows. Our running example is show S99: customer A requests seats 54–56 while customer B requests 56–57. Each request gets its whole set or none, and seat 56 cannot belong to both.

A hold is a durable business record reserving seats until a server deadline, such as five minutes. A database row lock is a short concurrency mechanism used while creating or changing that record. Keep the hold for minutes and the transaction for milliseconds; never leave database locks open while a customer enters payment details.

The seat map may lag by two seconds and is advisory. Hold creation targets a 500 ms 95th-percentile latency after admission, with success acknowledged only after the hold is saved under the durability policy explained below. During an unsafe database partition, pause allocation. For payment, allow a bounded processing interval and disclose that a late successful charge may require a refund if the seats have already been released.

Ask whether buyers select exact seats or only a ticket category, whether a cart may span shows, and whether the waiting room must guarantee strict arrival order. This design chooses exact seats within one show and bounded admission without strict first-arrival allocation.

02Functional requirements

1. Browse a show. List shows and display seat layout, prices and advisory availability.

2. Hold selected seats. Reserve a requested set of up to ten seats together, returning either the complete hold and its deadline or a conflict.

3. Pay and confirm. Start payment for an eligible hold, confirm the booking when both payment and seat ownership permit it, and recover a late successful charge through refund handling.

4. Retrieve the outcome. Let an authorized customer recover hold, payment and booking status after retries or a lost browser response.

03Non-functional requirements

These are illustrative interview assumptions, not product facts or measured benchmarks. Confirm them before choosing components, then validate the completed design under the stated workload. Here p95 means the 95th-percentile latency: 95% of measured requests take no longer than that value. Report errors and rejected work alongside latency; a fast failure is not a successful outcome.

1. Burst and latency. Plan for 10,000 seat-map reads/s during an on-sale burst. Use 500 admitted hold attempts/s as a load-test assumption and target 500 ms p95 hold creation after admission; waiting-room delay is a separate metric.

2. Map freshness and hold lifetime. Target advisory seat maps no more than two seconds behind for 99% of normal-load refreshes. Choose a five-minute initial hold and a fixed two-minute processing deadline when checkout begins; a late provider outcome may still need refund recovery.

3. Inventory consistency. Never allocate one show-seat to two live holds or bookings. A multi-seat request receives every requested seat or none, and expiry cannot release a newer owner’s seats.

4. Durability and safe failure. Acknowledged holds and bookings must survive one database-node failure under synchronous durable replication and safe failover. Pause allocation when authority is unsafe; payment-provider completion has no unconditional deadline.

5. Security and retry safety. Authorize hold/status access using the customer or secure guest session. Reuse scoped request and payment identities, verify provider evidence and keep raw card data outside this service.

04Complete the booking flow with one authority

Begin with a booking application, a relational database and an external payment provider. The application serves catalog reads, creates holds, scans deadlines and reconciles pending payments. Background tasks may initially run in the same deployment, but their work must exist durably in the database so a restart can resume it.

Customer A submits seats 54–56 with request key k7. One transaction claims that unique request identity, locks the selected seats in sorted order, checks that all are free and creates hold H7 plus its replay result. If any seat conflicts, the whole transaction rolls back. After commit, A receives the deadline.

At checkout, another transaction verifies H7 and changes it to processing with a bounded deadline. It stores payment attempt P3 and the fixed amount and currency before making the provider call. Provider success is then reconciled with the current hold. If H7 still owns every seat and remains eligible, confirm the booking atomically. Otherwise retain the payment outcome and schedule a refund without reclaiming the seats.

The browser reads booking status to resolve a lost response. A redirect from the payment page is neither proof of payment nor permission to allocate inventory.

05Size the on-sale burst, not just monthly averages

Assume three billion page views and ten million tickets sold in a thirty-day month. Dividing by 2,592,000 seconds gives roughly 1,157 views/s and 3.86 tickets/s on average. If orders contain two tickets, that is about 1.93 orders/s. These averages conceal the workload that matters: thousands of customers attempting the same show at once.

A burst of 100,000 shoppers opening a show in ten seconds creates 10,000 map reads/s. At 50 KB per response, origin traffic would be 500 MB/s before overhead. A 99% cache hit rate reduces origin requests to about 100/s, although customer-facing edge bandwidth remains.

If a load test supports 500 admitted hold attempts/s at 20 ms mean service time before queuing, roughly ten transactions are active on average. This is an illustrative budget, not a universal database capacity. Waiting on overlapping seat rows can dominate even when CPU is idle.

Store hall geometry once and keep show-specific price and allocation separately. For 20 million show-seat rows/day at 100 bytes each, raw daily inventory is 2 GB. Five years is about 3.65 TB before indexes, replicas and backups; archival policy can keep completed shows out of the hot transaction database.

06Give holds, payments and retries separate identities

Interfaces

Create the worked seat hold

POST /shows/S99/holds

Hold request values

seat IDs:      54, 55, 56
quote version: the version of the price the customer accepted
request key:   k7

Successful hold result

hold:     H7
seats:    54, 55, 56
deadline: server-issued hold expiry

Stored records

Store request results under show, authenticated session and key, including a payload fingerprint. Retrying k7 returns H7; reusing it for different seats conflicts. Claim the key within the transaction before allocating seats so a duplicate cannot report a conflict against its own first successful request.

Index active holds by state and deadline for expiry, and bookings by owner for recovery. An outbox row records notification or refund work in the same transaction as the business change. A signed-in customer or secure guest session owns the hold; knowing H7 is not sufficient authorization.

07Prove the all-or-nothing seat decision

Keep one show’s seats and holds in a database that can update them together in one transaction. For new hold creation, use one transaction:

1. Lock requested seat rows in ascending seat ID order.

2. Check the quote and every current allocation.

3. Write the entire hold. If the transaction cannot obtain a valid full set, leave no partial reservation.

A wins seats 54–56 first. B's transaction eventually locks seat 56, sees H7 and aborts its request for 56–57. Seat 57 does not remain reserved by B merely because it was free. If B wins first, A fails symmetrically. Unique seat keys and transactional checks protect the actual current allocation; a distributed cache lock is unnecessary for this baseline.

The same lifecycle operations use a consistent order: hold row, its immutable seat set in sorted order, then the payment-attempt row where needed. Re-read state after acquiring locks and handle bounded deadlock retries. Creation may use its own ordered seat lock path because its new hold is not yet visible to other operations.

A deadline is part of validity even if an expiry worker is late. To release a due hold, verify that each seat still belongs to that hold. An old cleanup attempt must never free a seat that now belongs to a newer allocation.

08Resolve the payment and expiry race explicitly

The payment provider and our database do not share one transaction. Before calling the provider, store P3, set H7 to processing and store a fixed deadline two minutes after checkout starts. Retries reuse P3 under the provider's supported idempotency contract. A timeout leaves the outcome unknown, not declined; the service queries the provider or processes verified callbacks for that same attempt.

At confirmation, lock H7 and its seats, check the authoritative database clock after waiting for locks, and require H7 to be processing, unexpired and still owner of every selected seat. Verify the provider account, attempt, successful outcome, amount and currency. If all checks pass, record payment success, booking and booked seats in one transaction. Duplicate success notifications return the existing outcome.

Now pause the provider response until after H7 expires. Expiry releases 54–56; B creates H8 for 56–57. When P3's success arrives, H7 is no longer eligible and seat 56 belongs to H8. Record the successful charge and unique refund work. Do not resurrect H7. B keeps the seats; A sees refund recovery rather than a false booking.

Refund work also needs a stable external identity and reconciliation. Submitting a refund is not proof it completed. An authorization-then-capture provider workflow may reduce this risk, but it still needs a defined policy for uncertain external outcomes.

09Cache browsing and control entry to scarce inventory

Move catalog, static hall geometry and short-lived seat maps behind caches when read bursts dominate. Include map timestamps and avoid caching personalized hold status as public content. Collapse concurrent cache refreshes so an expired popular map does not send thousands of identical database reads.

Bound hold attempts before they occupy database connections. A waiting room or admission service issues short-lived grants; the hold transaction validates and consumes a grant if admission is active. Rate-limit seat hoarding by account/session and risk signals. Admission limits simultaneous work; it cannot increase the number of seats for sale.

For the interview baseline, promise bounded admission and explain the fairness policy without claiming strict first-arrival seat allocation. Several simultaneously admitted customers can still race, and network timing affects who commits first. A strict first-in-first-out policy requires durable waiting order and tighter grant sequencing, trading utilization and throughput for stronger fairness.

Partition independent shows when aggregate storage or writes exceed one database. Sharding by show keeps the seat-set transaction local; sharding by movie unnecessarily combines many performances of a blockbuster. One very hot show still sends competing allocations to the same inventory database. More web servers do not remove that shared-seat conflict.

10Keep cleanup, notifications and failover recoverable

Expiry workers scan the durable deadline index in bounded batches. They perform the same guarded transitions as interactive operations, so restarting a worker or processing a deadline twice is safe. Cleanup may delay availability, but cannot extend the validity of an expired hold. Payment reconcilers scan unresolved attempts independently of browser activity.

The outbox drives map invalidation, booking notifications and refund work. Delivery may duplicate or arrive late. Events include booking versions, and the client retrieves current status after a gap rather than treating arrival order as state order. A notification outage can delay user awareness without undoing a booking.

Use synchronous durable replication of the authoritative database to meet the promised one-node failure tolerance. Safe failover must preserve acknowledged holds and stop the old primary from accepting writes. Changing DNS does not prevent the old primary from continuing to write. During uncertainty, show waiting or temporary failure rather than a reservation that was never safely committed.

Backups protect against deletion and corruption that replication repeats. Restore a test show, compare seats, holds, payment attempts and replay results, and reconcile external payments before resuming allocation. A restored inventory table alone does not establish which provider charges remain unresolved.

11Measure correctness, contention and recovery age

Monitor admitted hold latency, lock wait, transaction aborts, active-hold age, map freshness, queue delay and provider-unknown backlog. Track the oldest unresolved payment and refund, not just their counts. A single forgotten charge can be important even when aggregate checkout success looks healthy.

Run invariant checks for duplicate seat allocations, confirmed holds missing selected seats and inconsistent booked states. Test overlapping seat sets, duplicate request keys, worker crashes before and after commit, delayed success after expiry and a callback arriving twice. Stop expiry workers deliberately: holds should become invalid at their deadlines even though free-seat cleanup is delayed.

Verify webhook signatures on the raw provider payload and validate the event against the stored attempt. Keep card data with the provider and store tokens or references. Protect hold/status endpoints against guessing and unauthorized cancellation. A secure guest session needs the same ownership checks as a registered account.

For upgrades, deploy readers that understand a new lifecycle state before enabling writers that create it. Roll out to a small group of shows and retain a rollback path that understands already-created records. Correctness depends on every writer respecting the same transitions, not merely on the newest checkout endpoint.

12Check the design against its requirements

Use the numbered requirements to check the final design. FR refers to the functional list; NFR refers to the non-functional list. Performance rows specify tests still required, not achieved benchmark results.

13Rapid revision

Remember: The map suggests availability; the transaction reserves seats. A late charge cannot take seats from a newer hold.

Close by tracing A's seats 54–56, B's conflicting 56–57, and P3 arriving after expiry. This demonstrates the actual design more clearly than listing databases, queues and caches. State that strict waiting fairness and multi-show atomic carts are stronger contracts requiring additional coordination.

14Optional prompt variant: reserve every night of a hotel stay

This is an alternative interview prompt: reserve hotel rooms across several nights instead of seats for one performance. Keep the main ticket-booking design unchanged. The new difficulty is that a stay consumes capacity on every occupied night, and a shortage on one night invalidates the whole request.

Model inventory by (hotelId, roomType, localDate), with capacity, held quantity and booked quantity. Available quantity is capacity − held − booked. The room type promises a category such as a standard double; assigning a particular physical room is a separate hotel operation. Use hotel-local calendar dates and the interval [checkIn, checkOut): checkout day consumes no night. Reject invalid dates, excessive stay lengths and missing inventory rows rather than guessing their capacity.

A guest requests one standard double from November 5 through November 8. The occupied nights are November 5, 6 and 7:

The result is rejection of the whole stay. No hold remains on November 5 or 7. Reserving each night in a separate committed transaction would instead leave the guest with an unusable partial booking.

Keep each hotel’s inventory in one database transaction scope. Reserve the stay as follows:

1. Authenticate the guest. In the reservation transaction, claim a stable request identity with a fingerprint covering hotel, room type, dates, quantity, price and currency.

2. Lock all required nightly inventory rows in increasing date order.

3. Confirm that every row exists and has sufficient available quantity.

4. If all checks pass, increase held quantity on every night and create one reservation with its nightly allocations, server-issued expiry and replay result in the same commit.

Browsing a cached availability calendar does not reserve anything.

Use the existing bounded payment-processing flow without keeping inventory locks open during provider calls. Confirmation locks the reservation and its nightly rows, rechecks its current eligibility and atomically changes every allocation from held to booked. Expiry or permitted cancellation changes reservation state and releases the corresponding quantities together. Each transition checks the prior state, so duplicate workers cannot release or confirm the same capacity twice. A late payment success cannot reclaim nights already released; recover the financial outcome through the stated refund policy.

Test two overlapping stays, a missing middle-night row, an expired hold after lock waiting, a lost commit response and two expiry workers. PostgreSQL’s row-lock and deadlock guidance supports the concrete transaction mechanism. Multi-hotel packages spanning independent databases need a separate reservation workflow; this example promises one hotel’s all-night atomic reservation.

Recall the key ideas

Answer from memory before opening each card. Explain why the choice works and what it costs. Revisit missed cards tomorrow.