System requirements

Functional:

1. View Movies/shows.
2. Book Movies/shows.
3. Cancel Movies/shows

Non-Functional:

1. The view service should be highly available.
2. The booking service should be highly consistent.
3. System should be partition tolerant.
4. low latency for View service.
5. Booking service should be able to handle high number of concurrent requests.

Capacity estimation

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

API design

host - www.bookMyShow.com

1. GET /v1/show/:showId ?date=?&loc=? -> returns all shows for particular date and location.

1. POST /v1/book/:showId

{

tier:""

date:""

location:""

}

Database design

Core Entities -

1. User
2. Show
3. Ticket

DB Schema -

1. User (Id,name,phone,address)
2. Show (Id,Name,location,time)
3. Ticket (Id,UserId,ShowId,price,timestamp)

High-level design

1. Client (browser)
2. Load balancer (distribute requests to the backend servers)
3. View Service
4. Booking service
5. Separate database instances for viewing/booking the tickets.
6. Cache can be used to cache frequently viewed events.

Request flows

1. For viewing a part the request will go from client/browser to the Load balancer which will forward the request to the View Service. View service will check the cache if it has cached data for the service. if yes, it will return the data back to the client.

1. If the cache does not have the data, it will query the main DB for the record and return the data to the client.

1. For the booking service, the client will send the request to LB which will forward the request to the Booking service. Booking service will acquire pessimistic lock on the record in the DB with skip lock for a specific TTL. If the transaction is completed within that time, the success message is sent. If the TTL expires then the resource is released.

Detailed component design

1. Each service be it booking service or View service will scale horizontally.
2. View service DB will be in master/slave replication to handle increased load.
3. DB for booking service can be shared to handle increased load.
4. We can take the showID as the shardId for database sharding and use consistent hashing to distribute the load among the shards.

Trade offs/Tech choices

1. I chose MySQL as the database choice because of the data format and the ACID guarantees.
2. Redis for being vendor agnostic and good cache performance.

Failure scenarios/bottlenecks

Future improvements

1. Analytics and fault handling