System requirements
Functional:
- List movies playing in theaters near me at different times of the day(shows)
- Check availability of tickets for different shows
- Open seat map and view seat availability
- Book tickets for seats A,B,C.. in theatre X for movie Y on day D
- Payment for seats
- Email confirmation
- Cancellation
not in scope
- movie registration and theater schedule updates
- user login
Non-Functional:
- Strongly consistent for seat reservations - once paid seat is guaranteed, during payment a 15 min reservation is created and no others can get the seats
- Eventually consistent for showing availability and seat map. For peak demand periods, availability update can be delayed by 5 min and seat map view by 15 min.
- Low latency for website
Capacity estimation
10M users in US
At most 1000 concurrent users interested in a show during peak times, average 50.
10 movies per week playing in 10k theaters in US
API design
GET /movies?name=<>&date=<>&location=<>
Reuired: loc
Reponse
{
"amc": {
"thor": {
"time"[2pm, 6pm], "id":123
}
},
}
GET /show?theater=<>&movieid=123&time=<>
Response
showId: 154
10 seats available
GET /show/seatMap?theater=<>&movieid=123&time=<>
Response: {
row1: [1,2,3,5]
row2: [2,7,8]
...
}
POST /reservation?showId=<>
body
{
seats : [(rowId,seat num)...]
}
POST /book
Database design
Movie DB
Theater
- id
- name
- location
- seatMap
Movie
- id
- name
--------------------------------
Shows DB
Show
- show id
- movie id
- theater id
- date
- time
- seatMapId
SeatMap
- id
- list<row>
------------------------
Reservation
- id
- ttl
- state (confirmed, pending)
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...
Request flows
When browser attempts to make a reservation, an entry is created in reservations DB with TTL of 15 min. seatMap
Detailed component design
If there are many concurrent requests for the same seat map, it may become a hotspot and none of the users may be able to complete their reservation. In case a movie is popular(based on hit rate and prior knowledge), the seat map can have its own shard and each row can be migrated to a separate column.
Rate limiting may be needed to limit bad actors like misbehaving 3rd party aggregators/resellers. An algorithm like token bucket based on source IP can be used. Also a DDOs solution like cloudflare can bve used to prevent abuse of reservations API for unauthenticated clients.
For seat availability display, approximate counters like HyperLogLog can be used to efficiently display weakly consiustent view.
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?