Design BookMyShow

Ticket booking platforms like BookMyShow handle millions of concurrent users rushing to grab seats the moment a blockbuster release goes live. Behind that seamless experience lies a carefully engineered system that balances high availability, low latency, and race-condition-free seat reservation at scale. In this blog, we’ll break down the architecture decisions that make such systems work under pressure.

Requirements

Starting with the functional requirements of the system

1. User should be able to search for events/shows.
2. User should be able to view an event details like venue, date, artist etc.
3. User should be able to book the tickets for an event.

Now, let’s list down the non-functional requirements

1. System should be highly available for searching and viewing th events.
2. System should be highly consistent when it comes to ticket booking.
3. System should be scalable and have low latency specially for searching and viewing events details.

Capacity Estimations

For such type of services we can assume approx. 10 million DAU. These services are read heavy as users browse the events more as compared to ticket booking. Let’s assume for 5 search or detail viewing request from each user daily

total requests = 50 million/day = 600 requests/second (approx)

Peak traffic comes during second half of the day and at that time this number can be upto 4–5 times more. So 2000–2500 requests/day is the number that our system should be able to handle.

Entities and APIs

Core entities in this system are User, Event, Booking, Ticket, Venue (physical location for an event).

APIs are the following

1. GET /events/<event_id> → To fetch the details for an event.
2. GET /events/search/keyword={keyword}&start={date}&end={date}&pageSize={page_size}&page={page_number} → To fetch the events searched by user
3. POST /booking/<event_id> → To book the user’s ticket for an event.

High Level Design

Let’s start with completing our functional requirements one by one

View Event

User should be able to view the details of a specific event like name, date, artists, venue, seat mapping etc. We can simply have a event service behind the API gateway and load balancer which can fetch all these details from the database based on event id. In database, we can have tables for events, performaers, venue and when user will request for a specific event, the service will use these database tables to fetch the required details.

Search Events

We also need to allow the users to search for events based on keywords, venue, artists, date etc. We can have a search service which can recieve all the search queries from users and this service will be connected with the database and query it based on the filters recieved from user. This can be slow to search for results like this but we will optimize it later.

Book Tickets

The main challenge for this functionality if to avoid the two or more users trying to book the same seat in the same event. This requires the strong consistency, so we need a database with transactions. We can use database like PostgreSQL with new tables like bookings and tickets. Also we can create a new service like booking service to tackle this functionality and connect it with an external service for handling payments. Once this external service completes the payment transaction then it can notify back the original booking service. But this will come only after handling the booking consistency which we will see in deep dive section.

Design Deep Dive

How to handle the booking consistency?

In system like this we can see that there is a timer which tracks the time until you complete the purchase. This is a method to reserve the tickets for a user so that no other user can book the same ticket meanwhile you are completing your payment. But we need to make sure that the ticket is locked/reserved for the user while they are checking out and how can we do that? We need a system with temporary reservation that can expire automatically like if user not able to book the ticket in given time then the reserved seat should get available for others automatically.

We can implement a distributed lock with TTL (time to live) using Redis. Redis gives automatic key expiration and lock acquisition and release is also extremely fast (because of in-memory DB). When user selects a ticket, acquire a lock in redis with a defined TTL. If user completed the purchase then this ticket will be updated in database as booked and lock will get released from redis from our application code. If TTL expires then the redis will release the lock on its own. Key-value pair in redis will be ticket_id with user_id so that we can confirm that the user who booked the ticket is the same who reserved it. Also we need to show the updated seats status to other users when one user reserved the seat, so for that we can update the database with the status reserved when user selects the seat and timer starts and if booking completes then update the status to booked else to available considering the redis as our source of truth.

What if the TTL expires while transaction is going on? Simple answer is to extend the TTL once the transaction is initiated.

How to optimize events searching?

Querying the database for events based on filters can be slow and also a heavy load on database during peak hours. Obviosuly we can create indexes and optimize the sql query but still that won’t be enough. So we can use full text search engine like ElasticSearch. ElasticSearch can be a powerful tool here to optimize the search and handle heavy traffic. It is based on inverted index (TF-IDF) which allows it to quickly locate and retrive the data by mapping unique words to documents or records stored. But for this we need to sync elasticsearch with our database carefully.

How to handle millions of users simultaneously?

We know that our system is read heavy so there will be peak hours where number of users searching or viewing event details will be in millions so to handle this we can simply follow the rule book and implement caching, loading balancing and horizontal scaling of servers. For popular events or common search terms, we can simply cache the results with TTL.

Architecture Diagram