---
# System prepended metadata

title: Designing a ticket reservation system

---

> Ashraf Haib

# Designing a ticket reservation system

Tell me how you might design a system whose purpose is to reserve one or more available tickets for a given event name.

Your system should allow callers to reserve a number of tickets for the event for 20 minutes while payment for the tickets is secured by another system.

Assume for the purposes of this exercise:

* Events are at venues all over the world
* All tickets are of equal value (no "club seats", etc)
* All callers are equal (no tiered or preferred ticketholders, etc)

And here are some rough requirements for the system:

* You will need to handle requests for 10,000 active events at any given time
* The 10,000 active events will have between 1,000 and 100,000 tickets available for them
* At any given time, you might need to handle 100,000 concurrent callers to your system
* You should aim to minimize request latency for the system's globally-distributed users
* You should aim to minimize the impact of a regional failure to users outside of that region

Some questions to get you started:

* What might a top-level API for your system look like?
* What would a 1000-ft architecture of your system look like?
* How might you store the data involved in your system?
* What might the schema look like for the data involved in your system?
* What parts of the data might need to be cached, if any? What might you use for caching?
* How might you handle concurrent requests for the same event? For the same ticket blocks?
* How might you handle errors returned by the payment processing service?
* How might you think about the reliability and availability of your system? * How do you think about blast radius and handling failures across the various system components?
* What kind of mechanisms might you put in place to evolve the system over time?