Home/Blog/Ticketmaster’s System Design
Home/Blog/Ticketmaster’s System Design

Ticketmaster’s System Design

15 min read
Jan 16, 2025
content
Requirements for Ticketmaster
Functional requirements
Nonfunctional requirements
Estimations for Ticketmaster
Servers estimation for Ticketmaster
Storage estimation for Ticketmaster
Bandwidth estimation for Ticketmaster
API design for Ticketmaster
Design of Ticketmaster
Detailed System Design of Ticketmaster
Additional considerations for Ticketmaster’s design
Time-out mechanism
Data structures
Handling wait-lists
Message queue integration
Challenges in Ticketmaster’s design
Concurrency handling
Solutions
Fault tolerance and high availability
Solutions
Data partitioning and scalability
Solutions
Security
Solutions
Conclusion

Imagine trying to snag tickets to a sold-out Taylor Swift concert. Millions of fans worldwide are competing for the same seats simultaneously. We need to ensure a smooth and fair ticketing process. This is the challenge of online real-time ticketing systems like Ticketmaster.

These systems have revolutionized booking tickets for events, movies, and concerts. Platforms like Ticketmaster and BookMyShow provide a user-friendly experience, allowing customers to quickly search for events, reserve seats, make payments, and access tickets digitally.

However, building such systems is no easy feat. They must handle extremely high traffic, ensuring everyone has a fair chance to get tickets while preventing errors and delays.

Key takeaways:

  • Designing a real-time ticketing system like Ticketmaster requires balancing availability, scalability, and performance, especially during high-demand events, to ensure fair access for all users.

  • Effective API design and concurrency management are critical components. They utilize optimistic and pessimistic locking mechanisms to prevent issues like double booking.

  • Scalability planning is essential; adopting horizontal scaling, autoscaling strategies, and microservices architecture can facilitate growth as more cities and events are added to the platform.

  • Data partitioning and redundancy, through techniques like sharding and geographical data distribution, are necessary to manage increased load and ensure high availability on a global scale.

  • Addressing security challenges, such as unauthorized access and data breaches, requires a combination of role-based access control, encryption, and fraud detection mechanisms.

Designing a scalable online ticketing system like Ticketmaster is a fascinating technical challenge because such systems have to handle millions of concurrent requests. This blog breaks down the System Design, database design, API structure, and scalability considerations for building a high-performance ticketing system. I will also share my experience as a FAANG engineer and interviewer.

Challenges in designing online ticket booking systems
Challenges in designing online ticket booking systems

Let’s start with the requirements for designing such a system.

In my experience as an interviewer, this step is crucial for designing any system. A solid foundation is the first key to acing your System Design interview.

Requirements for Ticketmaster#

Ticketmaster’s requirements are functional and nonfunctional (quality concerns).

Functional requirements#

  • List cities, cinemas/events

  • Search for movies/events

  • Reserve and purchase seats/tickets

  • Manage bookings

  • Process payments

  • Generate and validate seats/tickets

Nonfunctional requirements#

  • Availability: The system should be highly available to serve users.

  • Scalability: The system should handle millions of users, especially during event sales.

  • Performance: The system should have low-latency responses, particularly for seat selection.

  • Reliability: The system should ensure no double-booking or seat overselling.

  • Fault tolerance: The system should tolerate server failures with minimal impact.

  • Security: The system should prevent fraud, protect user data, and secure payment processing.

We now have our requirements figured out, so we can discuss the back-of-the-envelope estimates for a Ticketmaster-like system. Scaling the system according to demand is one of the most necessary features of modern system design. If not done well, the system will buckle under pressure.

Learn how to ace the System Design interview!

Cover
Grokking the Modern System Design Interview

System Design interviews are now part of every Engineering and Product Management Interview. Interviewers want candidates to exhibit their technical knowledge of core building blocks and the rationale of their design approach. This course presents carefully selected system design problems with detailed solutions that will enable you to handle complex scalability scenarios during an interview or designing new products. You will start with learning a bottom-up approach to designing scalable systems. First, you’ll learn about the building blocks of modern systems, with each component being a completely scalable application in itself. You'll then explore the RESHADED framework for architecting web-scale applications by determining requirements, constraints, and assumptions before diving into a step-by-step design process. Finally, you'll design several popular services by using these modular building blocks in unique combinations, and learn how to evaluate your design.

26hrs
Intermediate
5 Playgrounds
18 Quizzes

Estimations for Ticketmaster#

The first step in designing systems is to estimate the resources required to facilitate good performance during many user requests. Let’s start by calculating the number of application servers we might need.

Servers estimation for Ticketmaster#

Assuming:

We have:

These are the minimum servers we will need for running the system daily. But what happens if there’s a surge in traffic, i.e., each user makes a request simultaneously? In that case, Reqs/secReqs_{/sec}becomes equal to the DAU.

These estimates work well in an interview setting, but you can improve upon these numbers. See this guide on back-of-the-envelope calculations for more details.

Storage estimation for Ticketmaster#

Assuming:

  • We have 1,000 cities.

  • Each city has 5 cinemas.

  • There are, on average, 1,000 seats per cinema.

  • There are, on average, 2 shows per cinema per day.

The schema to store a booking might look something like this:

TABLE Booking(
ID int, # 4 bytes
Num_Seats int, # 4 bytes
Show_ID int, # 4 bytes
Movie_ID int, # 4 bytes
Seat_Numbers varchar(50), # 50 bytes
Booking_Time timestamp, # 4 bytes
)

This comes out to about 70 bytes.

So:

We will need around 256 GB of storage to store a year’s data, which is close to nothing for a huge service like Ticketmaster.

Bandwidth estimation for Ticketmaster#

We will use the 700 MB/day estimate from before to calculate the network requirements for Ticketmaster.

Learn more about back-of-the-envelope estimations (BOTECs) here.

Now that we have completed the important estimates, we can determine how to meet the functional requirements.

Note: Calculating these estimates is important to help shape our design. For example, we now know that we may need many servers on standby to serve the users under peak load, so adding a load balancer and monitoring to the design is necessary.

Next, we can design the key API endpoints for this system.

API design for Ticketmaster#

We need to define endpoints to meet our major functional requirements.

Note: This may not be needed in every interview; however, API design is an essential skill for System Design interview candidates.

  1. searchMovies(city, cinema, timing)
    This call returns available movies and showtimes for a given location and time.

GET /searchMovies
{
"city": "Seattle",
"cinema": "Downtown Cinema",
"timing": "7 PM"
}
// Example Response
{
"movies": [
{
"id": "mov-123",
"title": "Action Movie",
"showtimes": [
{
"id": "show-456",
"time": "7:15 PM",
"availableSeats": 50
},
]
},
]
  1. reserveSeats(showId, userId, seats)
    This reserves available seats for a short time while the user completes payment.

POST /reserveSeats
{
"showId": "show-456",
"userId": "user-123",
"seats": ["A1", "A2"]
}
// Example Response
{
"reservationId": "res-789",
"expirationTime": "2024-12-20T10:00:00Z"
}
  1. confirmBooking(reservationId, paymentInfo)
    This confirms the booking after payment is processed.

POST /confirmBooking
{
"reservationId": "res-789",
"paymentInfo": {
"cardNumber": "**** **** **** 1234",
"expiryDate": "12/24",
"cvv": "123"
}
}
// Example Response
{
"bookingId": "book-101",
"status": "confirmed"
}
  1. cancelBooking(bookingId)
    Cancels an existing booking, releasing the seats.

  2. getBooking(bookingId)
    Retrieves booking details for user reference or customer service.

Learn more about API Design here!

Cover
Grokking the Product Architecture Design Interview

Designing a modern system involves navigating complex requirements to create cohesive and functional designs. As a designer, you'll need to understand these requirements and guide the design process effectively, addressing both broad and specific topics in product design. In this course, you will design APIs for well-known systems such as YouTube, Stripe, and Zoom, understanding how these APIs integrate into the larger product ecosystem. You'll begin by discussing recurring concepts, using them as foundational building blocks. You'll trace the lifecycle of each API call from the client to the service to meet functional requirements. Additionally, you'll use a reference back-end implementation to demonstrate how an API call operates, with a focus on minimizing client-visible latency to create competitive APIs and products. This course prepares you for product architecture design interviews by examining systems from a client's perspective and discusses how client calls interact with the back-end system.

20hrs
Intermediate
4 Playgrounds
28 Quizzes

By defining the endpoints first, we can have a pretty good idea of how to design Ticketmaster. As I said before, our system will need monitoring and load balancers. Let’s discuss what key building blocks you might need to design the Ticketmaster service.

  • Cache: This will ensure quicker response times.

  • Databases: These will store information related to cinemas, movies, cities, and users. We will use SQL databases (e.g., MySQL, Postgres, etc.) as they are ACID compliant.

  • Blob stores: These will store multimedia content, e.g., movie covers.

So, we have:

Components in the Ticketmaster System Design
Components in the Ticketmaster System Design

Design of Ticketmaster#

We will start with a high level and then work toward the detailed design of Ticketmaster.

High-level design of Ticketmaster
High-level design of Ticketmaster

As we can see in the diagram above, the load balancer routes requests to the web servers, which can be imagined as the application’s web pages. These requests then go to the application servers (holding the application logic), which interact with the database and cache servers to store the relevant information.

This design meets our functional requirements, but we must also ensure our non-functional requirements. Let’s examine the specifics of this design to create our detailed design of Ticketmaster.

Detailed System Design of Ticketmaster#

Let’s expand on the high-level design and identify services that meet the functional requirements listed below.

Detailed design of Ticketmaster
Detailed design of Ticketmaster

  • User: This is the system’s entry point where users initiate requests such as searching for shows, booking tickets, and making payments.

  • Load balancers:

    • Distribute incoming traffic across multiple web servers to prevent any single server from becoming a bottleneck.

    • Improve reliability by redirecting requests if a web server fails.

    • Support horizontal scaling by allowing more web servers to be added as needed.

  • Web servers:

    • It mostly serves as the frontend layer, processing user requests and forwarding them to relevant services, such as application servers.

    • Entertains requests for serving static content like HTML, CSS, images (movie covers, for example), and scripts. Web servers cache the frequently requested static content to reduce the processing delay of such requests.

    • Web servers can handle session management, often using cookies or tokens to maintain user state and enable seamless navigation. They also enforce security protocols (such as HTTPS) to protect the application and users’ data from unauthorized access.

  • Application servers: Serving as the backend layer of the system, these servers host the core business logic of the system. This layer includes multiple microservices:

    • Booking service: Manages ticket reservations, seat allocation, and booking confirmations.

    • User service: Handles user-related functions, such as profile management, preferences, and account details.

    • Cinema service: Manages data about cinemas, showtimes, movie details, and seat configurations. Interact with database and cache servers to fetch and update data as required.

  • Cache:

    • Stores frequently accessed data, such as movie schedules, seat availability, and user session data.

    • Helps reduce the load on the persistence layer and improves response times by serving cached data.

    • Uses in-memory caching solutions like Redis or Memcached to deliver low-latency access to critical information.

  • Databases:

    • Store and manage persistent data for core entities, including users, bookings, cinema information, and payment records.

    • Use replication and partitioning strategies to ensure high availability and scalability.

  • Blob stores:

    • Store large binary files, such as movie posters, promotional images, and trailers.

    • Ensures that large files are stored separately from the main database to optimize storage and retrieval performance.

  • Monitoring:

    • Continuously tracks system health, server load, response times, and error rates.

    • Sends alerts if any component is experiencing issues, allowing for prompt intervention to maintain system stability.

    • Provides analytics on usage patterns, helping with capacity planning and proactive maintenance.

Point to ponder

1.

Imagine a challenge of high concurrency during peak times, especially for popular events, which may lead to conflicts in seat reservations and double-booking issues. How can we solve this?

Show Answer
Q1 / Q1
Did you find this helpful?

Additional considerations for Ticketmaster’s design#

We can still improve on this design in some ways:

Time-out mechanism#

An active reservation system holds seats for a set period to prevent double booking. Implementing a time-out ensures that reserved seats are released if payment isn’t completed within the time frame.

For example, Ticketmaster might hold a reserved seat for 10 minutes. If the user doesn’t pay within this period, the reservation is automatically canceled, and the seat becomes available for others to book. This is often implemented using background tasks or scheduled jobs that periodically check for expired reservations.

Data structures#

Track seat reservations using hash maps or in-memory data stores, enabling fast lookups and releasing expired holds.

Hash maps or in-memory data stores like Redis are excellent choices. For instance, each seat can be represented as a key in the hash map, with its value indicating the reservation status (e.g., “available,” “reserved,” “booked”). This allows the system to quickly check a seat’s availability and update its status when a reservation is made, confirmed, or canceled.

Handling wait-lists#

Popular events often sell out, leaving many users disappointed. A wait-list service provides a fair way to manage this demand. Implement a priority queue to manage the wait-list and notify users if seats become available.

A priority queue is a suitable data structure to manage the wait-list efficiently. This ensures that users who join the wait-list earlier get priority when seats become available. For example, if someone cancels their booking, the system can automatically offer the seat to the first person on the wait-list.

Message queue integration #

Use a message queue (e.g., RabbitMQ) to handle wait-list notifications and seat availability updates.

A message queue can handle wait-list notifications and seat availability updates in a ticketing system. When seats become available, the system can send messages to the queue. Consumers (i.e., wait-listed users) can receive these messages and attempt to book the seats. This decouples the different components of the system, improving scalability and reliability.

This kind of discussion is important at the end of your System Design interview when you are evaluating your design.

Challenges in Ticketmaster’s design#

Ticketmaster is a unique System Design problem due to the challenges it presents. It is quite different from the usual System Design problems like designing social media apps (Instagram, Twitter/X), streaming services (YouTube, Netflix), Ride-hailing apps (Uber, Lyft), etc., because it relies on high concurrency to be considered functional.

Concurrency handling#

Handling concurrent requests for the same seats can lead to conflicts and potential overselling.

Solutions#

  • Optimistic locking: This method uses versioning to detect conflicts. A version field is attached to each seat record. When a user initiates a booking, the system records the initial version. Upon booking confirmation, the system checks if the version remains unchanged. If modified, the transaction is rolled back, indicating another user has acquired the seat.

  • Pessimistic locking: This approach employs exclusive locks on seat records. When a user initiates a booking, the system acquires a lock on the corresponding seat record. Other transactions attempting to access the same record are blocked or queued until the lock is released. This guarantees exclusive access but can increase latency, particularly under high contention.

  • Distributed locking: A centralized lock manager is necessary for distributed systems. Tools such as Redis or Zookeeper can fulfill this role. When a user attempts to book a seat, the system acquires a distributed lock associated with that seat. This lock is managed across all servers, preventing concurrent access from any user regardless of their connection point.

Distributed locking in action
Distributed locking in action

Each concurrency control mechanism has trade-offs:

  • Optimistic locking is generally less restrictive but may lead to more failed transactions if conflicts are frequent.

  • Pessimistic locking ensures consistency but can introduce higher latencies, especially during peak loads when many users compete for the same resources.

  • Distributed locking adds complexity but is essential for scalable systems operating across multiple servers.

Fault tolerance and high availability#

Handling server or network failures can disrupt user experience and availability. Server or network issues can cause downtime, impacting user access.

Solutions#

  • Redundancy: Redundancy involves deploying multiple instances of the ticketing system’s components. This could include having multiple web servers, application servers, and database servers. If one server fails, the redundant instances can take over, ensuring uninterrupted service. For example, a load balancer can distribute traffic across multiple web servers. If one server goes down, the load balancer automatically redirects traffic to the remaining operational servers.

  • Replication: Replication focuses on data redundancy. It involves creating multiple copies of the database and distributing them across different servers or data centers. If one database fails, the system can continue operating using the replicated data.

  • Failover: Failover mechanisms ensure automatic traffic redirection to standby servers in case of a failure. This often involves monitoring systems that continuously check the health of servers. If a server fails, the monitoring system triggers the failover process, rerouting traffic to a standby server. This ensures minimal downtime and uninterrupted service for users.

Data partitioning and scalability#

As the system grows, a single database becomes a bottleneck, unable to handle all requests efficiently.

Solutions#

  • Horizontal partitioning (sharding): This involves distributing data across multiple databases based on a specific key, such as city, event type, or venue. For example, all events in Los Angeles could be stored in one database, while events in New York are stored in another. This allows for distributing the read and write load across multiple databases, improving performance.

    • Shard key selection: Choosing the right shard key is crucial. It should distribute data evenly and align with query patterns. For instance, sharding by city is a good choice if most queries are city-specific.

    • Cross-shard queries: Handling queries that span multiple shards requires careful consideration. Techniques like distributed query processing or data duplication can be employed, but they add complexity.

    • Data consistency: Maintaining data consistency across shards can be challenging. Distributed transactions or eventual consistency models might be necessary.

  • Vertical partitioning: This involves splitting a large table into smaller tables based on their indexes. For example, the first hundred rows can be stored in database A, while the next hundred can be stored in database B. While vertical partitioning can improve performance for specific queries, it can also increase complexity when retrieving data across multiple tables.

Horizontal vs. vertical partitioning
Horizontal vs. vertical partitioning

To address scalability over time, it is essential to consider the roadmap for evolving the Ticketmaster system as demand increases. As new cities and events are added to the platform, the infrastructure must be capable of scaling horizontally. This involves distributing the load across additional servers for application and database layers to maintain performance and reduce latency. Implementing an autoscaling strategy can be beneficial, where servers are dynamically added or removed based on traffic demand, ensuring optimal resource utilization. Additionally, adopting microservices architecture facilitates scaling individual components independently, allowing teams to develop and deploy changes without impacting the entire system.

Moreover, incorporating a robust data partitioning strategy is crucial for accommodating future growth. As more data accumulates, horizontal sharding across multiple database instances becomes vital for efficiently managing increased read and write operations. Selecting an appropriate shard key that aligns with business logic and query patterns will help evenly distribute the load while minimizing cross-shard queries, which can degrade performance. Considering the global expansion, geographically distributed data centers ensure low latency and high availability for users across different regions.

Security#

Unauthorized access and data breaches could expose sensitive information, including payment data.

Solutions#

  • Authentication and authorization: Implement role-based access control for users and admins to ensure secure access.

  • Data encryption: Encrypt sensitive data to protect against unauthorized access, particularly in payment processing.

  • Fraud prevention: Detect and prevent duplicate bookings and suspicious activities to reduce fraud risks.

Security-ensuring techniques for Ticketmaster
Security-ensuring techniques for Ticketmaster

Point to ponder

1.

Can we use a rate limiter to make the design more secure?

Show Answer
Q1 / Q1
Did you find this helpful?

Conclusion#

Building a distributed system like Ticketmaster involves careful trade-offs to achieve scalability, reliability, and high performance. This blog discussed key decisions around API design, database management, and concurrency control, each critical for a successful implementation.

Future improvements could include AI-driven recommendations, advanced fraud detection, and further performance optimization, but our current design lays a solid foundation for a resilient, high-performance ticketing platform. Now, you know how to tackle one of the most common System Design interview questions. Here’s what you can see next:

If you feel ready, test your skills by taking a System Design mock interview on plenty of commonly asked System Design interview questions, or prepare for the interview by learning System Design using our flagship course.

Frequently Asked Questions

What technology stack does Ticketmaster use for its online ticketing system?

Ticketmaster relies on a combination of modern technologies such as microservices architecture, in-memory caching systems like Redis, and SQL databases for data integrity. This technology stack ensures scalability, low latency, and reliable performance during peak user activity.

What cloud platform is Ticketmaster’s infrastructure based on?

What is the primary objective of Ticketmaster’s ticketing system?

How does Ticketmaster ensure security and prevent double bookings?


Written By:
Umer Draz
Join 2.5 million developers at
Explore the catalog

Free Resources