Get an invite

Design a ticketing system System design interview practice, out loud

A voice interviewer that follows your reasoning, on a canvas you both see. Here is the brief, the numbers you can ask for, and what the interview goes into.

  • System design
  • 30 or 45 minutes
  • At Mid, Senior and Staff level
Practise this one out loud

Private beta · one free session when you're in

A desktop browser and a microphone.

The brief

The interviewer reads it out, then waits for you.

Interviewer
“Design a ticketing system for concerts and shows. Fans open a show, pick seats on a seat map, keep them for a few minutes while they pay, and get their tickets on their phone. Some shows sell out within minutes of going on sale. Start wherever you like; the canvas is yours.”

The numbers you can ask for

The interviewer answers these when you ask, and never volunteers them. For anything else it says the brief doesn't fix that: choose an assumption and say it out loud.

You askThe interviewer answers
How many users?100 M fans buy at least once a year; ~10 M visit on a normal day
How many tickets are sold?~1 M tickets a day on a normal day, across ~50 k shows on sale
How big is a big on-sale?For the biggest shows, ~5 M people try to buy at 10:00 for 60 k seats, and they sell out in about 10 minutes
How many seats does a show have?From a few hundred to 60 k in a stadium; most under 5 k
How many tickets per order?Up to 8
How long can a fan keep seats before paying?10 minutes; after that the seats go back on sale
How is payment taken?Through an outside payment provider; a charge takes 2 to 10 s and sometimes times out
How fast must it be?The seat map loads in under 1 s; taking a seat answers in under 500 ms
How up to date must the seat map be?A few seconds behind is fine
Availability?Buying 99.95 %
Can a seat ever be sold twice?Never; and a fan who was charged always gets their tickets
Is X in scope?In: a show's seat map, keeping seats while paying, paying, tickets on the fan's phone, big on-sales. Out: search and recommendations, resale between fans, refunds, organisers' tools beyond putting a show on sale, scanning tickets at the door

Be ready for these

The interviewer starts with the requirements and ends with the wrap-up. In between, it follows you, so the order is yours. The answers are yours too: this page doesn't give them.

  1. What exactly are you building, and what numbers must it hold?First
  2. Can you outline the whole system before you go deep on any part of it?
  3. Where do the seats live, and how does a fan see which ones are free?
  4. What happens when two fans want the same seat, and how are seats kept while someone pays?
  5. How does paying turn kept seats into tickets, and what if the payment goes wrong?
  6. What happens at the moment a big show goes on sale?
  7. Where is your design weakest, and what would you build first?Last

What's expected at your level

Your Report reads you against the bar for the level you pick. Each level keeps what's below it and adds a line.

See all twelve bars →
Scoping
  • Before drawing, says one thing the system must do, and one assumption about who uses it or how much.
  • +Names something that is out, and sizes the reads and the writes separately.
Estimation
  • Turns one given number into a new figure, out loud, and uses a number to justify one choice.
  • +Says the unit, and uses a figure they worked out to size a named component.
Solution design
  • Connects a client, a service and a store, and walks one use case through them.
  • +Walks two use cases end to end, and says what each component is for.
Data and interfaces
  • Says what is stored and in what kind of store, and one field kept beside the content.
  • +Says why the store fits what it holds, and names one API call with its inputs and output.
Scalability
  • Treats reads and writes as separate paths, and says which one is busier.
  • +Says how the busier path scales out.
Reliability
  • Says what happens when a named part fails, and one way the system recovers.
  • +Says what happens to the work in flight, and a concrete limit on the recovery.
Consistency and async
  • Says which work happens later and what starts it, and what the user is told, and when.
Trade-offs
  • Names an alternative to one choice, and a reason tied to the problem.
  • +Gives a reason specific to this system, and names what their own pick costs.
Technical depth
  • Explains what one technology does in the design, and why it fits.
  • +Explains how one mechanism works inside, and one of its limits.
Operability
  • Names a metric for the main path, and the value that should alert someone.
Communication
  • On the final canvas, every box is named and joined to its flow.
  • +Talks while drawing: names each box as it goes down.
Scoping
  • Before drawing, says one thing the system must do, and one assumption about who uses it or how much.
  • +Names something that is out, and sizes the reads and the writes separately.
  • +Sets a target (a latency, an availability) and names the part of the design it constrains.
Estimation
  • Turns one given number into a new figure, out loud, and uses a number to justify one choice.
  • +Says the unit, and uses a figure they worked out to size a named component.
  • +Sizes both sides: a figure for the writes and a figure for the reads.
Solution design
  • Connects a client, a service and a store, and walks one use case through them.
  • +Walks two use cases end to end, and says what each component is for.
  • +Gives every use case in the brief a path.
Data and interfaces
  • Says what is stored and in what kind of store, and one field kept beside the content.
  • +Says why the store fits what it holds, and names one API call with its inputs and output.
  • +Chooses the store by how it is looked up.
Scalability
  • Treats reads and writes as separate paths, and says which one is busier.
  • +Says how the busier path scales out.
  • +Puts a cache or a CDN on the busy path and says what it holds, or shows none is needed.
Reliability
  • Says what happens when a named part fails, and one way the system recovers.
  • +Says what happens to the work in flight, and a concrete limit on the recovery.
  • +Handles a second failure, in a different part of the design.
Consistency and async
  • Says which work happens later and what starts it, and what the user is told, and when.
  • +Says how the client learns the work finished, or how stale a value may be.
Trade-offs
  • Names an alternative to one choice, and a reason tied to the problem.
  • +Gives a reason specific to this system, and names what their own pick costs.
  • +Says when their choice would stop being right, and what they would change then.
Technical depth
  • Explains what one technology does in the design, and why it fits.
  • +Explains how one mechanism works inside, and one of its limits.
  • +Does the same for a second mechanism, elsewhere in the design.
Operability
  • Names a metric for the main path, and the value that should alert someone.
  • +Says how a change rolls out safely.
Communication
  • On the final canvas, every box is named and joined to its flow.
  • +Talks while drawing: names each box as it goes down.
  • +Walks the whole design once, near the end.
Scoping
  • Before drawing, says one thing the system must do, and one assumption about who uses it or how much.
  • +Names something that is out, and sizes the reads and the writes separately.
  • +Sets a target (a latency, an availability) and names the part of the design it constrains.
  • +Names the requirement that would change the architecture, and what would change.
Estimation
  • Turns one given number into a new figure, out loud, and uses a number to justify one choice.
  • +Says the unit, and uses a figure they worked out to size a named component.
  • +Sizes both sides: a figure for the writes and a figure for the reads.
  • +Names the figure that limits the design, and says why.
Solution design
  • Connects a client, a service and a store, and walks one use case through them.
  • +Walks two use cases end to end, and says what each component is for.
  • +Gives every use case in the brief a path.
  • +Names the part that changes first as the system grows, and what it becomes.
Data and interfaces
  • Says what is stored and in what kind of store, and one field kept beside the content.
  • +Says why the store fits what it holds, and names one API call with its inputs and output.
  • +Chooses the store by how it is looked up.
  • +Says how the schema or an API changes without breaking clients.
Scalability
  • Treats reads and writes as separate paths, and says which one is busier.
  • +Says how the busier path scales out.
  • +Puts a cache or a CDN on the busy path and says what it holds, or shows none is needed.
  • +Names what fails first at ten times the load, and the fix.
Reliability
  • Says what happens when a named part fails, and one way the system recovers.
  • +Says what happens to the work in flight, and a concrete limit on the recovery.
  • +Handles a second failure, in a different part of the design.
  • +Says how a failure is kept from spreading, and what keeps working meanwhile.
Consistency and async
  • Says which work happens later and what starts it, and what the user is told, and when.
  • +Says how the client learns the work finished, or how stale a value may be.
  • +Says what happens when that work fails or runs twice.
Trade-offs
  • Names an alternative to one choice, and a reason tied to the problem.
  • +Gives a reason specific to this system, and names what their own pick costs.
  • +Says when their choice would stop being right, and what they would change then.
  • +Names the decision that is hardest to reverse, and why.
Technical depth
  • Explains what one technology does in the design, and why it fits.
  • +Explains how one mechanism works inside, and one of its limits.
  • +Does the same for a second mechanism, elsewhere in the design.
  • +Shows how one of those limits shaped a choice.
Operability
  • Names a metric for the main path, and the value that should alert someone.
  • +Says how a change rolls out safely.
  • +Says how cost is watched or kept in bounds.
Communication
  • On the final canvas, every box is named and joined to its flow.
  • +Talks while drawing: names each box as it goes down.
  • +Walks the whole design once, near the end.
  • +Answers each question in its first sentence, then gives the detail.

Thirty minutes. Out loud. On this brief.

Pick your level when you start. Pause for coaching if you get stuck, and read your Report a few minutes after.

Private beta · one free session when you're in

Other interviews

System design · 30 min · Junior to Senior

Design a URL shortener

Someone pastes a long link and gets a short one back; anyone who opens the short link lands on the original page.

System design · 30 or 45 min · every level

Design a chat app

People send text messages to each other from a phone or a laptop.

System design · 30 or 45 min · Mid to Staff

Design a video platform

People upload a video from a phone or a laptop, and anyone can watch it — on a slow connection, on a TV, anywhere in the world.