DEV Community

Abhishek Prajapati
Abhishek Prajapati

Posted on

BookMyShow/Ticketmaster system design

#systemdesign #hld

Introduction

What is BookMyShow

It is a platform which allows users to book an ticket to events like movie, concert, shows etc.

Steps to tackle this question

  1. Requirements

    1. Functional requirements: These are the core functionalities of our system
    2. Non Functional requirements: These are the qualities of our system

  2. Entities

    These are the data bodies that would be used to help us understand what kind of data is being moved in our system

  3. APIs

    These are the endpoints that would be used to fulfill our functional requirements and other functions to help services communicate between each other

  4. HLD

    This design would satisfy our functional requirements

  5. Deep Dive:

    This is where we are going to full fil our Non functional requirements

With the roadmap ready, let's get started

1. Requirements

Functional Requirements

We want our systems to fulfill the below core functionalities

  1. Search for shows/movies/events in their city
  2. View the details of the event(this refers to all the above mentioned)
  3. Book a ticket for the event

Non-functional requirements

Here we will try to decide the quality of our system

  1. We want consistency in our booking service since we don't want multiple people to book the same seats for an event
  2. Availability for searching an event
  3. Low latency for searching
  4. Scalability to handle surges, maybe to book a ticket to a famous convert(like book tickets for the cold play concert in india, boy that was an experience)
  5. Prioritize reads >> writes since we would mostly searching and looking at events when compared to booking tickets

2. Entities

We are now going to decide which data types are we going to use in our system

  1. Event - Use to store details about a events
  2. User - store details about the user
  3. Ticket - Store the information about the event reservation
  4. Performer - Store details about then performer who is going to perform at an event
  5. Venue - Details about a particular venu, ex: Capacity, location, amenities etc

3. APIs

Now we are going to define the endpoints that are going to satisfy our functional requirements

For search/view an event

Request:
GET /events/:eventId

Response:
Event, Performer, Venue, Tickets[]
Enter fullscreen mode Exit fullscreen mode

Search for an event

Request:
GET /search?term={searchTerm}&location={locationOfEvent}&type={typeOfEvent}&...

Response:
Partial<Event>[]
Enter fullscreen mode Exit fullscreen mode

We get a list of partial Event types so that we get the basic idea about the event and if we want to know more details then we can click on the event and that will hit the /events/:eventId for more details

Book a ticket

This is going to be a little tricky since we don't want multiple users to book the same seats we are going to use 2 phase to tackle this.

Phase 1 - we lock the seats for some time so that user can book the seats within some time let's say x mins. If booking fails then we open the tickets to other users.

Request:
POST /booking/reserve
header: JWT session token
body: {
    ticketId: "ad98384109ffe0"
}
Enter fullscreen mode Exit fullscreen mode

Phase 2 - User books the ticket and we mark the seats booked

Reqeust:
POST /booking/confirm
header: JWT session token
body: {
    ticketId,
    paymentDetails (3rd party payment provider details)
}
Enter fullscreen mode Exit fullscreen mode

Now that we have decided on the Entities and APIs, let get into High level design

4. High Level Design

HLD Design

5. Deep dive

Now that we have satisfied a functional requirements we can go deep diving into a non functional requirements
The area of improvements are

  1. Improving the search speed which is the low latency search

Introducing elasticsearch for querying the events which stores the events against tokenized terms (term: [event1, event2 ...])

we can use the event CRUD service to update the data in both database and the elastic search but that would add complexity to our event CRUD service since it would be updating both the elasticsearch and the database'

In order to better handle this updation of data we will use change data captures which is CDC. So first we will make an update to database and then eventually the database will utilize CDC and send that data to elasticsearch

Option1 vs Option2

We can also cache popular events which will reduce the search time

  1. Scalability to handle surges from popular event

Problem: if a user is checking seats for a popular event then they might face an issue because a lot of people are checking that event at the same time so this can lead to users having delayed response or no response at all

Possible Solutions

  1. Long Polling
  2. Websockets
  3. SSE

So in order to tackle the issue of multiple uses trying to book seats for popular event we can take the approach of using virtual queue where N users will be inserted into the queue. Once the users are in the queue we can have something like an SSE which will send an event to the user mentioning that now they can book their ticket.

The waiting queue can be configured to only be used for popular events, so this way we don't have to use queue every time.

Updated HLD diagram

Updated HLD Diagram

That's all folks hope you had a great time reading this blog and I hope to see you again and if you have any suggestions or questions please comment down below.

Top comments (0)