System requirements

Functional:

1. List movies playing in theaters near me at different times of the day(shows)
2. Check availability of tickets for different shows
3. Open seat map and view seat availability
4. Book tickets for seats A,B,C.. in theatre X for movie Y on day D
5. Payment for seats
6. Email confirmation
7. Cancellation

not in scope

1. movie registration and theater schedule updates
2. user login

Non-Functional:

1. 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
2. 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.
3. 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?