In this tutorial, I am going to give an overview of the Movie Ticket Booking System Design.

Scenario based questions are very common for experienced professionals in the interview room. Among them system design is the mostly asked question because of its coverage right from the software requirements to its end production.

Requirements for a Movie booking system:

• User should book a ticket based on the below.

  1. Current Location or City.
  2. Movies available.
  3. Theatres or screen’s near by.
  4. Select the show timings.
  5. Block the seats.
  6. Generate ticket.
• Concurrency in the application
• Security
• Database for maintaining Transactions as well as unstructured data

So these are the basic requirements for ticket booking system and now you can see the list of API’s for back-end development and by name itself API’s are self explainable.

List of API’s:

• getCities
• getTheatreByCity
• getMovieByTheatre
• getScreenByMovie
• getShowByScreen
• getAvailableSeatByShow
• bookSeat
• sendTicketByMailOrSMS
• postReviews

Once we are ready with all the back-end API’s that suffice our requirements. Visit the bookmyshow.com or fandango.com and check the flow of booking a ticket to relate it with the below image.

As shown in the above image when user makes a request to getCities, getTheatreByCity and getMovieByTheatre. These request are routed to the available application server via load balancer to a distributed cache from which all the basic information can be fetched.

What is distributed cache?
A distributed cache is a system that pools together the random-access memory (RAM) of multiple networked computers into a single in-memory data store used as a data cache to provide fast access to data. Distributed caches are especially useful in environments with high data volume and load.

Once the user selects the show time, request is routed to the theatre API or database to fetch the available shows and seats from the theatre database.

Now user can select the seat and is redirected to the payment gateway with multiple options. On a successful payment, application server sends and request to the theatre API/database to block the seats for the user and tickets are sent via email or SMS.

Here comes the real question of designing the concurrency. Since multiple people access the application at a single point of time and tries to book the same seats.

We can use synchronization at the application level and handle the concurrency. But here are multiple instances up and running due to which handling the concurrency at application level is not possible.

So we can implement the concurrency or locking mechanism at database level in multiple ways depending on the isolation levels. If it is read committed or update happens within the payment gateway timeline, one row will be locked corresponding to the seat id and once the seat is locked or booked other people cannot book the same seat as it is updated in the database.

In the above image it is shown that we are using two databases i.e., RDBMS for structured data NoSQL database for unstructured data. All the data pertaining to the user, theatre, movies, bookings comes under the structured data which has a pre-established relationships between one and the other, Whereas reviews, comments etc comes under unstructured data.

Suggestions processing is nothing but recommended system that shows the movies based on the user likes, booking or watch history.