A million people, ten thousand seats, one minute. Holding seats without double-selling, and a waiting room to survive the rush.
What is on this board
Parts
- Fan Web app
- Waiting room Service
- Booking Service · Go
- Seat holds Cache · Redis
- Seats and orders Relational DB · Postgres
- Payment Payment provider · Stripe
- Expired holds Message queue
- Tickets Email / SMS / push
- Events Search index · Elasticsearch
- Event pages CDN
- Hold in Redis, sell in Postgres Decision record
- Bots Risk
How they connect
- Fan → Event pages: event page
- Fan → Events: find a show
- Fan → Waiting room: wants seats
- Waiting room → Booking: your turn
- Booking → Seat holds: hold this seat
- Booking → Payment: pay
- Payment → Booking: paid
- Booking → Seats and orders: seat is sold
- Seat holds → Expired holds: ten minutes passed
- Expired holds → Seats and orders: release
- Booking → Tickets: send tickets
Notes and decisions
- Waiting room: Lets people in at the rate the system can take
- Seat holds: SET seat NX EX 600
- Hold in Redis, sell in Postgres: A unique index on (event, seat) is the last defence. It can't take the rush alone, so Redis absorbs it.
- Bots: They buy everything in the first second. Waiting room, CAPTCHA, per-account limits.
More like this
News feed, like TwitterFan-out on write or on read? Timelines in a cache, the celebrity problem, and how a post reaches millions of followers.
News feed, like TwitterFan-out on write or on read? Timelines in a cache, the celebrity problem, and how a post reaches millions of followers.
URL shortener, like BitlyThe first system design interview question: key generation, heavy reads, a cache in front, and click analytics off the request path.