</> MAANG.io
system design · 301

Advanced

Master system design interviews with scalable architecture patterns, distributed systems, and real-world design challenges.

0/480 solved 0% complete

Ticket Booking System Design

The prompt sounds like a shopping cart: "Design a ticket booking service like Ticketmaster. Fans browse events, pick specific seats on a seat map, hold them for a few minutes while they pay, and get tickets. The hardest case: a stadium show with 60,000 seats goes on sale at 10:00 and three million fans show up."

Most candidates draw the cart. Events table, seats table, an orders table, a payment call. Then the questions start. Two fans tap seat 8 in the same instant: who gets it, and how do you know the other one didn't? A fan holds two seats and closes the tab: when do those seats come back? Three million people press refresh at 10:00:00: what does your database see? The seat map says a seat is free and the hold fails: is that a bug? And when half the queue is bots, what does "fair" even mean?

The Trap Built Into a Familiar Question

Two failures show up again and again:

  • The Shopping Cart: a clean CRUD design with no answer for contention. It reads availability, then writes a booking, and between the two another fan books the same seat. Or it "locks the seat in Redis" and has never thought about what a failover does to that lock. Signal: hasn't owned a system where two writers want the same row.
  • The Autoscaler: hears "three million fans" and scales everything horizontally. But the seats for one show live in one place, and 3,000,000 requests a second is 150 times what the inventory can absorb. Adding web servers just delivers the stampede to the database faster. Signal: never asked what the bottleneck actually is.

The passing performance notices that the average day is tiny, about six orders a second, and that the design is driven by one moment. It makes the hold the single source of truth: one transaction that flips every requested seat from available to held, or none of them, with a short expiry built into the condition. It lets the seat map be a couple of seconds stale, because the hold, not the map, decides. It turns a 150× surge into a steady 67 admissions a second with a virtual waiting room that runs at the edge on signed tokens. And it is honest that most of the three million fans will go home without tickets, so the system should tell them early and fairly.

Sign in to continue reading

The rest of this lesson is available with a free account. Signing in with Google or Microsoft is free.

Sign in to read the full lesson

Sign in to MAANG.io

Use your Google or Microsoft account — no password to remember.

Continue with Google Continue with Microsoft

Please accept the terms above to continue.