Design a Ticket Booking Site Like Ticketmaster | Hello Interview System Design in a Hurry

Common Problems

Ticketmaster

Dealing with ContentionScaling ReadsReal-time Updates

By Evan King·Updated Feb 14, 2026·

Understanding the Problem

🎟️ What is Ticketmaster?
Ticketmaster is an online platform that allows users to purchase tickets for concerts, sports events, theater, and other live entertainment.

Functional Requirements

  1. Start your interview by defining the functional and non-functional requirements. For user facing applications like this one, functional requirements are the "Users should be able to..." statements whereas non-functional defines the system qualities via "The system should..." statements.
  2. Prioritize the top 3 functional requirements. Everything else shows your product thinking, but clearly note it as "below the line" so the interviewer knows you won't be including them in your design. Check in to see if your interviewer wants to move anything above the line or move anything down. Choosing just the top 3 is important to ensuring you stay focused and can execute in the limited time window.

Core Requirements

  1. Users should be able to view events
  2. Users should be able to search for events
  3. Users should be able to book tickets to events

Below the line (out of scope):

  1. Users should be able to view their booked events
  2. Admins or event coordinators should be able to add events
  3. Popular events should have dynamic pricing

FIRST QUESTION
What are the non-functional requirements of the system?

Non-Functional Requirements

Core Requirements

  1. The system should prioritize availability for searching & viewing events, but should prioritize consistency for booking events (no double booking)
  2. The system should be scalable and able to handle high throughput in the form of popular events (10 million users, one event)
  3. The system should have low latency search (< 500ms)
  4. The system is read heavy, and thus needs to be able to support high read throughput (100:1)

Below the line (out of scope):

  1. The system should protect user data and adhere to GDPR
  2. The system should be fault tolerant
  3. The system should provide secure transactions for purchases
  4. The system should be well tested and easy to deploy (CI/CD pipelines)
  5. The system should have regular backups

Defining the Core Entities

To satisfy our key functional requirements, we'll need the following entities:

  1. Event: This entity stores essential information about an event, including details like the date, description, type, and the performer or team involved.
  2. User: Represents the individual interacting with the system.
  3. Performer: Represents the individual or group performing or participating in the event.
  4. Venue: Represents the physical location where an event is held.
  5. Ticket: Contains information related to individual tickets for events.
  6. Booking: Records the details of a user's ticket purchase.

API or System Interface

The API for viewing events is straightforward.

GET /events/:eventId -> Event & Venue & Performer & Ticket[]

...

High-Level Design

Users should be able to view events

When a user navigates to www.yourticketmaster.com/event/:eventId they should see details about that event...

  1. The client makes a REST GET request with the eventId
  2. The API gateway then forwards the request onto our Event Service.
  3. The Event Service then queries the Events DB for the event, venue, and performer information and returns it to the client.

Users should be able to search for events

When users first open your site, they expect to be able to search for upcoming events.

  1. The client makes a REST GET request with the search parameters
  2. Our load balancer accepts the request and routes it to the API gateway with the fewest current connections.

Users should be able to book tickets to events

  1. The user is redirected to a booking page where they can provide their payment details and confirm the booking.
  2. Upon confirmation, a POST request is sent to the /bookings endpoint with the selected ticket IDs.
  3. If the transaction is successful, the booking server returns a success response.

Potential Deep Dives

1) How do we improve the booking experience by reserving tickets?

A better solution is to lock the ticket by adding a status field and expiration time on the ticket table. The ticket can then be in 1 of 3 states: available, reserved, booked. This allows us to track the status of each ticket and automatically release the lock once the expiration time is reached.

2) How is the view API going to scale to support 10s of millions of concurrent requests during popular events?

Great Solution: Caching, Load Balancing, and Horizontal Scaling

Caching:

Final Design

As you progress through the deep dives, you should be updating your design to reflect the changes you are making...

What is Expected at Each Level?

As a mid-level candidate, you should be able to craft a high-level design that meets the functional requirements you've defined...

This response should follow the desired format, focusing solely on the relevant content, removing any navigation links or advertisements as specified.