Marketplaces & booking
Seat sales - fifty thousand people, one hundred seats
queue, hold, expire, issue
What this board gets wrong on purpose
The tension
The waiting room does not remove the herd, it moves it: fifty thousand people now contend on one ordered structure per event instead of one seat key, and that structure is a single Redis shard because a position in a queue is meaningless unless one thing assigns it. If that shard is slow, nobody gets in and the sale looks like an outage; if it is lost, positions are lost and re-queueing an angry crowd is worse than the original problem. The hold TTL is the second unresolved choice: ten minutes is long enough to type a card number and long enough for a bot to squat the entire front block behind a single admitted session, and there is nothing on this board that can tell those two apart at hold time. The seat map is served from a cache that is seconds stale by construction, so the most common experience of a fast sale is clicking a seat that was already gone when the pixel was drawn.
1 · Requirements
This is not a high-traffic system. It is a low-traffic system with a sixty-second window in which it is the busiest thing on the internet, and every requirement below is about that window.
Ask these before designing
- Is fairness a product requirement or a legal one? "First come first served" and "random draw among everybody present at 10:00:00" are different systems. A draw removes the thundering herd entirely and most promoters refuse it.
- How long is the hold? Ten minutes is a card form on a phone on a train. It is also long enough for one admitted session to squat an entire front block.
- Can a seat be resold after a failed checkout? If yes, the seat map must be push-updated, which is a second fan-out system.
- Best-available or pick-your-seat? Best-available lets the server choose and collapses contention onto the server’s ordering. Pick-your-seat is what customers want and is strictly harder.
- What is the bot policy? Rate limits, device attestation and a purchase cap are all product decisions with legal consequences, not middleware.
- Does the queue survive a refresh? If a token is tied to a session cookie, a tab crash loses a place in line, which is the single most common support complaint.
Functional
- Show a seat map for an event, with prices and availability.
- Admit users into the purchase flow at a controlled rate, with a visible, honest position.
- Hold a chosen seat exclusively for a fixed window, then release it automatically.
- Issue a ticket that is permanently bound to exactly one seat.
- Enforce a per-account purchase cap for an event.
Non-functional
- A seat may never be issued twice. This is the only hard requirement. Everything else is negotiable under load.
- Admission decisions in under 100 ms, because the waiting-room page polls and a slow queue reads as a broken sale.
- Hold claim p99 under 50 ms, and it must FAIL fast: "taken" in 50 ms is a good outcome.
- 99.95% availability during an on-sale minute, measured per on-sale rather than monthly - a 30-second outage at 10:00:00 is a total failure that a monthly average hides completely.
- Peak-to-average on the hold path is about 300:1. Provisioned ahead of the on-sale from the event calendar; never autoscaled, because autoscaling reacts in minutes and this event lasts sixty seconds.
Explicitly out of scope
Payment processing internals, delivery and barcode rotation, secondary market resale, venue seat-map authoring, dynamic pricing.
The rest of this board
Available on Tier Slate
This page publishes the question. The answer — 5 more written pages, an 8-step narrated walkthrough and a 5-table schema — is the board itself, and it opens in Tierslate.
- 5written pages
- 8walkthrough steps
- 5tables30 columns
5 pages behind this one
- Capacity estimation
- Storage estimation
- Availability
- How it works
- Deployment plan
More boards
Two-sided systems where inventory must not be sold twice.