Design BookMyShow

Problem Statement:

Let’s design an online ticketing system that sells movie tickets like BookMyShow.
Similar Services: ticketmaster.com

Step-1: What is an online movie ticket booking system ?

A movie ticket booking system provides its customers the ability to purchase theatre seats online.

E-ticketing systems allow the customers to browse through movies currently being played and to book seats, anywhere and anytime.

Step-2: Requirements and Goals of the System

Functional Requirements:
Our ticket booking service should be able to list down different cities where its affiliate cinemas are located.
Once the user selects the city, the service should display the movies released in that particular city.

Customers should be able to search movies by their title, language, genre, release date, and city name.

Once the user selects the movie, the service should display the cinemas running that movie and its available shows.
The user should be able to select the show at a particular cinema and book their tickets.

The service should be able to show the user the seating arrangement of the cinema hall and the user should be able to select multiple seats according to their preference.

The user should be able to distinguish available seats from the booked ones.

Users should be able to put a hold on the seats for five minutes before they make a payment to finalize the booking.
The user should be able to wait if there is a chance that seats might become available – e.g. when holds by other users expire.

Waiting customers should be serviced fairly in a first come first serve manner.

Complete payment & show booking details

Non Functional Requirements:

The system would need to be highly concurrent. There will be multiple booking requests for the same seat at any particular point in time. The service should handle this gracefully and fairly.

The core thing of the service is ticket booking which means financial transactions. This means that the system should be secure and the database ACID compliant.

Step-3: Some Design Considerations

For simplicity, let’sassume our service doesn’t require user authentication.

The system will not handle partial ticket orders. Either user gets all the tickets they want, or they get nothing.
Fairness is mandatory for the system.

To stop system abuse, we can restrict users not to book more than ten seats.

We can assume that traffic would spike on popular/much-awaited movie releases, and the seats fill up pretty fast.

The system should be scalable, highly available to cope up with the surge in traffic.

Step-4: Capacity Estimation

If there are 2000 seats in each cinema and on average, there are two shows every day.

Let’s assume each seat booking needs 50 bytes (IDs, NumberOfSeats, ShowID, MovieID, SeatNumbers, SeatStatus, Timestamp, etc.) to store in the database.

We would also need to store information about movies and cinemas, let’s assume it’ll take 50 bytes.

Total storage in a day for all shows of all cinemas of all cities: 500 cities*10 cinemas*2000 seats*2 shows*(50+50) bytes = 2GB / day.
To store 5 years of this data, we would need around 3.6PB.

Step-5: System APIs

• GetUserLocation() // address Long Lat or Mumbai Pune...
• GetListOfCities()
• GetListOfEventsByCity(CityId)
• GetLocationsByEventandCity(cityid, eventid)
• GetMoviesByLocationandCity(CityId, LocationId)
• GetShowTiming(eventid, locationid)
• GetAvailableSeats(eventid, locationid, showtimeid)
• VarifyUserSelectedSeatsAvailable(eventid, locationid, showtimeid, seats)
• BlockUserSelectedSeats()
• BookUserSelectedSeat()
• GetTimeoutForUserSelectedSeats()

Parameters

Search Movies API

api_dev_key (string): The API developer key of a registered account, will be used to, among other things, throttle users based on their allocated quota.
keyword (string): Keyword to search on.
city (string): City to filter movies by.
lat_long (string): Latitude and longitude to filter by.
radius (number): Radius of the area in which we want to search for events.
start_datetime (string): Filter movies with a start datetime after this datetime.
end_datetime (string): Filter movies with a start datetime before this datetime.
postal_code (string): Filter movies by postal code / zipcode.
includeSpellcheck (Enum: “yes” or “no”): Yes, to include spell check suggestions in the response.
results_per_page (number): How many results to return per page. Maximum is 30.
sorting_order (string): Sorting order of the search result. Some allowable values : ‘name,asc’, ‘name,desc’, ‘date,asc’, ‘date,desc’, ‘distance,asc’, ‘name,date,asc’, ‘name,date,desc’, ‘date,name,asc’, ‘date,name,desc’.

SearchMovies(keyword, city, lat_log, radius, start_datetime, end_datetime, postal_code, include_spell_check, results_per_page, sorting_order)

Reserve Seats API

Parameters:
api_dev_key (string): same as above
session_id (string): User’s session ID to track this reservation. Once the reservation time expires, user’s reservation on the server will be removed using this ID.
movie_id (string): Movie to reserve.
show_id (string): Show to reserve.
seats_to_reserve (number): An array containing seat IDs to reserve.

Step-6: Database Design

Here are a few observations about the data we are going to store:

• 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.
• Comments and rating (Cassandra)

RDBMS: We have mentioned that we need ACID property in our system. Also, we have countries, cities, theatres in cities, multiple screens in these theatres, and multiple rows of seats on each screen. So here it is clear that we need a proper relationship representation. Also, we need to handle the transaction. RDBMS is fit for these cases. The portal will be read-heavy so we need to share the data by Geo or we need to use master-master slave architecture. Slaves can be used for reading and master for writing.

NoSQL: We also have a huge amount of data like movie information, actors, crew, comments, and reviews. RDBMS can not handle this much amount of data so we need to use the NoSQL database which can be distributed. Cassandra can be a good choice to handle this ton of information. We can save multiple copies of data in multiple nodes deployed in multiple regions. This ensures the high availability and durability of data (if a node goes down, we will have data available in other nodes).

Step-7: Detailed Component Design

Ticket Booking Workflow:

User searches for a movie.

User selects a movie.

User is shown the available shows of the movie.

User selects a show.

User selects the number of seats to be reserved.

If the required no. of seats are available, the user is shown a map of the theater to select seats, if not, user is taken to ‘step-8’ below.

Once the user selects the seat, the system will try to reserve those selected seats.

If seats can’t be reserved, we have following options:
Show is full; the user is shown the error message.

The seats user wants to reserve are no longer available, but there are other seats available, so the user is taken back to the theater map to choose different seats.

There are no seats available to reserve, but all the seats are not booked yet as there are some seats that other users are holding in reservation pool and have not booked yet. The user will be taken to a waiting page where they can wait until required seats get freed from the reservation pool. This waiting could result in following options:

If the required number of seats become available, the user is taken to the theater map page where they can choose the seats.
While waiting if all seats get booked, or there are fewer seats in the reservation pool than the user intend to book, the user is shown the error message.

User cancels the waiting and is taken back to the movie search page.

At max, a user can wait one hour, after that user’s session gets expired and the user is taken back to the movie search page.
If seats are reserved successfully, the user has five minutes to pay for the reservation.

After payment, booking is marked complete. If the user is not able to pay within five minutes, all their reserved seats are freed to become available to other users.