System Design: Movie Ticket Booking (BookMyShow)

5 min readSep 11, 2020

Watching a movie or an event is always a gives you enjoy in the theater, or at least it gives sometimes your mind relax to think differently from the regular tasks and rejoice the movie. Most of us have experience booking movie tickets online or at the counter. In India Book My Show(BMS) is the one that is a very popular ticket booking system eventually, other systems are also coming in the market but BMS popularity has not yet taken by other apps. We are going to discuss the system design of BMS.

Traffic And Storage Estimation

Let us consider during the weekend 1–5 billion user browse the app/website and they book close to 10 billion movie ticket in approx of 200 cities with 2000 seat. Imagine how big data we have to consider and as well for transactions.

200 cities * 200 cinemas * 2000 seats * 4shows * (100) bytes = 3GB / day

Problem Statement

Let us understand the problem statement or the requirement’s

Cities
list of movies released
List of cinema hall/ Theater
Different show times
Seating arrangements

These are the functional requirements we have whereas some non-function requirement also we have to consider for designing this application like

The system would need to be highly concurrent. There will be multiple booking requests for the same seat at any particular point in time. So proper handling of locking the records and transactions.
There are financial transactions involved. This means that the system should be secure and the database ACID compliant.

Service Creation

We can choose either SOAP or REST, I’ll consider the REST design due it gives the flexibility of lightweight and multiple platform.

searchMoviesserachCityloadMovileloadTheaterbookSeatseatDetails reserveSeat viewBookingloginUser

Database Design

Each City can have multiple Cinemas.
Each Cinema will have multiple halls.
Each Movie will have many Shows and each Show will have multiple Bookings.
A user can have multiple bookings.

The above diagram is basic RDBMS ER flow whereas it does not only depend on RDBMS but also NoSQL because the use-case like comment, reviews kind of big data can use some NoSQL engine. This has a very high read oriented application so it needs to be always active-active and master-master architecture for RDBMS. However, NoSQL deployed in the distributed node and it almost minimise latency.

It has the transactions process for ticket booking so definitely it has to follow ACID properties.

Caching

There is a cache under which all the requests and response first store and I think they might be using a write-through approach to sync DB and Cache. As per the diagram, it is using the cluster cache Redis.

Queue or Event handling

Once the ticket booking is confirmed then the system will send billing detail and booking information. This may be in form of pdf, HTML email template, and the process may take some time because once the payment and booking are confirmed it is no longer a sync process, and hence this task will handle async. The moment it receives in the queue application will snd mail, SMS to the client.

AI and ML process

There are some spark job will be running to get the recommendation or ratings the movie based on the user booking or movie booking etc.. A batch job put the data in KAFKA topic from there Spark job and store into HDFS. Then after AI/ML spark job to run and provide the recommendation.

Application Flow

The above flow diagram will explain to the flow of the ticket booking system. Though I will explain you entire flow.

Customer will browse BMS app or website, App will send the location detail to the application server.

The app server will fetch the movie detail and theater and load it into the app/website UI.

The user will select the movie and the app will load the all theater detail which is running those movies. The app server would have sent all the detail at first when the user location had fetched so there is no call required for the theater.

Then the user will select the theater and it will load the grid at this point it will fetch the latest seat information from the app.

The user will select a seat and proceed for the payment. At this point, the application will lock the record and proceed for the payment detail, once the payment is successful it will update the seat detail.

If payment fail or seat is unavailable by the time the payment gateway responds then it will not book the seat and if payment is successful then will process for the return amount.

If all well it will send the seat detail confirmation in SMS and email.

Seat Booking Process

How to handle concurrency, such that no two users are able to book the same seat. We can use transactions in SQL databases to avoid any clashes. For example, if we are using an SQL server we can utilize Transaction Isolation Levels to lock the rows before we can update them.

One thing to note here; within a transaction, if we read rows, we get a write lock on them so that they can’t be updated by anyone else.

Once the above database transaction is successful, we can start tracking the booking.

Our web servers will manage all the active users’ sessions and handle all the communication with the users. We are using caching which stores all Booking updates, seat details, Movie and theater details and keep syncing the database for both SeatReservation and WaitingForSeatService based upon the ‘ShowID’. This way, all reservations and waiting users of a particular show will be handled by a certain set of servers. Let’s assume for load balancing our Consistent Hashing allocates three servers for any Show, so whenever a reservation is expired, the server holding that reservation will do the following things:

Update the cache to remove the Booking (or mark it expired) and update the seats’ Status in ‘Seats’.
Sync the DB for the seat and booking details.
Notify the user that their reservation has expired.
Broadcast a message to all WaitingForSeatService servers that are holding waiting users of that Show.
Send a message to the WaitingForSeatService server holding the longest waiting user to process their request if required seats have become available.

Whenever a reservation is successful, the following things will happen:

The server holding that reservation sends a message to all servers holding the waiting users of that Show so that those servers can expire all the waiting users that need more seats than the available seats.
After receiving the above message, the client expires the existing session and it will request to fetch a fresh record of seat details.