Design Ticketmaster - System Design

System requirements

Functional:

List functional requirements for the system (Ask the chat bot for hints if stuck.)...

The platform should help me to select movies
It should list all the theatre which is running the movie along with showtime
On selection of movies I should be able to select seat.
The booked seat should be greyed out
On confirmation I should be able to make payment.
It should notify me with all the details

Non-Functional:

List non-functional requirements for the system...

The system should be available so it can serve millions of users at the same time
It should be scalable on increasing customer query it should not crash
Post seat selection the system should be strong consistent so that same seat is not assigned to multiple users.
It should have low latency to get the data about movie info but for payment latency can be compromised.

Capacity estimation

Estimate the scale of the system you are going to design...

100 Million Daily active users

Read QPS = 100M/100k = 1000

During peak hours = 2 * QPS = 2000

Write will be 1% of users who buys ticket

write QPS = 10

During peak hours = 20

So it is a read heavy system

API design

Define what APIs are expected from the system...

GET /v1/theatres/:locationId

Retrieve list of theatres for this location

Response:

data: [

{

theatreId:

address:{

}

email:

phone:

}

]

GET /v1/movies/:theatreId

We need to provide theatreId and it will return all the movies running in this theatre

Response:

data: [

{

movieId:

movieName:

timeslot:

}

]

GET /theaters/{theaterId}/movies/{movieId}/seats?datetime={dateTime}

This will give the information about seats for a specific theatre and for a specific movie running in that theatre

Response:

{

"theaterId": 123,

"movieId": 456,

"dateTime": "2024-09-25T18:30:00",

"seats": [

{

"position": "A1",

"occupied": true

{

"position": "A2",

"occupied": false

{

"position": "A3",

"occupied": true

{

"position": "B1",

"occupied": false

}

]

}

POST /v1/seats/hold

This request will to hold the seat for the specific movie

Request params

POST /tickets/hold

Content-Type: application/json

{

"theaterId": "123",

"movieId": "456",

"datetime": "2024-09-25T19:30:00",

"seatId": "A1"

}

It will return response based on the availability

200 OK:

{

ticketId:

Status: held

}

400 Bad Request:

If the theatreId, movieId is invalid

500 Internal server error

If not able to hold the seat please try again

GET /ticket/:ticketId/status

It will return the status of the ticket

POST /v1/payment

It will be available to make payment

Request Body:

{

ticketId:

info:{

creditcard no:

expiry date:

cvv no:

}

Response:

200 OK if the payment successful

Database design

Defining the system data model early on will clarify how data will flow among different components of the system. Also you could draw an ER diagram using the diagramming tool to enhance your design...

Theatre

TheatreID
Location
City
List<Show> shows

Show

ShowId
MovieId
TheatreId
Date showStartTime
List<Seat> bookedSeats

Seat

SeatId
Row
SeatCategory

Movie

MovieId
Name
Title
Duration

Bookings

BookingId
userId
createdTime
status : enum : held, booked, completed, expired
showId
List<Seat> bookedSeats

Database Choices

Relational Database for User, Booking, and Payment Data:
1. Reasoning: User data and booking information require strong consistency and relational structure to maintain data integrity and enforce ACID properties.
2. Database Type: Relational Database (e.g., PostgreSQL, MySQL).
3. CAP Theorem Focus: Consistency is prioritized to ensure accurate and reliable user information and booking details.
NoSQL Database for Event, Location, Reviews, and Comments Data:
1. Reasoning: Event details and location information may vary and evolve, requiring a flexible schema and scalability, making NoSQL databases suitable.
2. Database Type: NoSQL Database (e.g., MongoDB, Cassandra).
3. CAP Theorem Focus: Partition tolerance and availability are crucial to handle potential changes in data structure and support scalable operations.
Document Store for Search Data:
1. Reasoning: Search data benefits from a document-oriented storage approach, enabling fast and efficient retrieval of movie and event-related information.
2. Database Type: Document Store (e.g., Elasticsearch).
3. CAP Theorem Focus: Availability is emphasized for quick and responsive search capabilities.
Media Database for Media Files:
1. Reasoning: Multimedia files, such as movie trailers, require efficient storage and retrieval, making media databases suitable for this purpose.
2. Database Type: Media Database (e.g., Amazon S3, MongoDB with GridFS).
3. CAP Theorem Focus: Emphasis on Availability and Partition Tolerance to ensure media files are accessible and retrievable.
Key-Value Store for Metadata and Quick Lookups of popular events:
1. Reasoning: Metadata and quick lookups can benefit from a key-value store for simplicity and fast access to specific information.
2. Database Type: Key-Value Store (e.g., Redis).
3. CAP Theorem Focus: Emphasis on Availability and quick lookups, while still maintaining Partition Tolerance.

High-level design

You should identify enough components that are needed to solve the actual problem from end to end. Also remember to draw a block diagram using the diagramming tool to augment your design. If you are unfamiliar with the tool, you can simply describe your design to the chat bot and ask it to generate a starter diagram for you to modify...

Client: The client customer used to book a ticket. It could be a web app or mobile app.

Load Balance: Balance the traffic from client evenly to different servers. The load could be balanced with path based, round robin or consistent caching approaches.

Api Gateway: Api Gateway will be responsible with authentication, rate limiting and others.

CDN: Store static files, for example movie preview images, movie tailor and theater images. When user request static data, the request will be routed to the CDN which physically close to the client.

Info Service: Info service will be responsible to read request from clients. For example, get theater info, get movie info and get seat info.

Ticket Service: Ticket service will be responsible to update the database to hold a ticket and query a ticket status.

Task Scheduler: The task scheduler will be responsible to schedule a time after user hold a ticket. If the user didn't pay the ticket in a certain time (5 min or 10 min), the task scheduler will be responsible to update the status of the ticket.

SQL Database: The database will be responsible to store the information of the theater, movie, seat and ticket.

Database Cache: Will cache the SQL Database to read data faster.

Notification Service: Notification service will be responsible to send ticket confirmation notification to the client through SMS, email or push notifications.

Request flows

Explain how the request flows from end to end in your high level design. Also you could draw a sequence diagram using the diagramming tool to enhance your explanation...

Detailed component design

Dig deeper into 2-3 components and explain in detail how they work. For example, how well does each component scale? Any relevant algorithm or data structure you like to use for a component? Also you could draw a diagram using the diagramming tool to enhance your design...

Trade offs/Tech choices

Explain any trade offs you have made and why you made certain tech choices...

Failure scenarios/bottlenecks

Try to discuss as many failure scenarios/bottlenecks as possible.

Future improvements

What are some future improvements you would make? How would you mitigate the failure scenario(s) you described above?