Case study: Design ticketmaster

August 14, 2019

Introduction

It is a good idea for me to learn how to write down the most important things I learn from lecture learning. The system design is called Design a ticketmaster. It takes a lot of time to put together the detail about the design, the database table, columns, and then relationship, and all other details. I like to write a short case study how to manage the design in 45 minutes time range.

Case study

I am new to the system design. I started from 2016 Amazon onsite interview, and then I started to learn how to work on better.

1. Requirement - gather requirement

Functional requirement:
ticket Booking service
client purchase API
...

Non-Functional requirement:
highly concurrent; Same seat may have multiple booking request.
ticket booking, financial transactions, ACID compliant.

Design consideration

1. To simplify, no user authentication
2. No partial ticket order
...

Capacity estimation
Traffic estimation:
3 billion page view per month, 10 million tickets a month

Storage estimates:

500 cities
10 cinemas each city
2000 seats each cinema
two shows every day

Seat booking needs 50 bytes (IDs, NumberOfSeats, ShowID, MovieID, ...

to store all the data about all shows of all cinemas of all cities for a day:
500 cities * 10 cinemas * 2000 seats * 2 shows * (50 + 50) bytes = 2 GB/ day

Five year data, 3.6TB

5. System APIs

SearchMovies(keyword, city, ...
return: (JSON)

6. Database design

A few observations about the data we are going to store:
1. Each city can have multiple cinemas
2. Each cinema will have multiple halls
3. Each movie will have many shows and each show will have multiple bookings
4. A user can have multiple bookings

Tables:
Movie
Show
booking
User
Cinema
Cinema_hall
Show_seat
Payment
City
Cinema_Seat

7. High level design

clients -> load balancer -> multiple web servers -> Application servers -> cache servers and database

8. Detail component design

It is so interesting to watch the slide show how the booking is designed, and how to reserve the seat and then allow user to book, make payment.

Two daemon services:
1. One to keep track of all active reservations
2. One to remove any expired reservations from the system

It is so interesting to learn that data structure is chosen for ActiveReservationService

9. Concurrency

NO two users are able to book same seat

'Serializable' is the highest isolation level and guarantees safety from Dirty, Nonrepeatable, and Phantoms reads.

10 Fault tolerance

Service crash, read from database

11. Data partitioning

MovieID or showID,

Two service partitioning

Consistent hashing based on ShowID