System requirements


Functional:

List functional requirements for the system (Ask interviewer if stuck)...


users:

customers

  • purchase movie tickets
  • create an account

admins

  • ticket inventory, pricing, promotion
  • add/remove listings, theatres, showtimes


customer create an account and login

admins have their own special panel


features:

  • user registration and authentication
  • display a list of available movies, showtimes, theatres
  • genre, casting, ratings, trailers
  • users can pick seats in theatres
  • update seat availability in real time
  • payment processing for ticket purchase
  • support different payments
  • send confirmation with booking details
  • notify customers of changes or cancellations
  • customers can add movie ratings and add reviews
  • display overall rating for each movie
  • movie management - add movies, update existing movies, set showtimes
  • theatre management - add new theatres, edit existing theatres, update showtimes at each theatre


Because each set of actions can be encompassed by a category, they will be separated by microservices and live in each respective microservice. For example, payment-related actions will live in the payments service.


Non-Functional:

List non-functional requirements for the system...


non-functional requirements

  • needs to be fault tolerant for both users and admins at any given time
  • real time write updates - writes needs to be fast
  • read delays are minimal - reads also need to be fast
  • low latency
  • peaks will increase reads/writes
  • scale dynamically


the system needs to be able to scale dynamically as there are more traffic so we will need to look at things like horizontal scaling, reads needs to be fast since there are more reads than writes so we can consider caching reads for more popular movies and theatres, and it needs to be highly performant and available to users and admins to provide a seamless experience. because there can be high peak traffic, we want to ensure that the load is also evenly distributed through load balances that can be scaled and the load balancers will handle distributing traffic to ensure that no single server is overwhelmed causing application degradation. because we want to ensure that admins and users are routed properly, we will also need an api gateway. to ensure high performance, we need to ensure that the application survives hardware faults and network failures and that there are no single points of failures. since we need highly available data but also highly consistent data, we can look at the CAP theorem - we cant have both so we will need to make tradeoffs. this will depend on the data model but we can also utilize consistent hashing to help with load and availability.


given that we will also need to host trailers and they are video media, we want to also consider using a CDN to host and serve files. since we need low latency, we will want to have multiple CDNs that serve content to users based on their locale.


in order to ensure high performance and fault tolerance, we will also need to consider monitoring and logging with tools such as elastic search, logstash, and kibana and monitoring such as grafana.


because each action is an event, we will also want to consider an event driven architecture using apache kafka to handle decoupling of actions and services.


Capacity estimation

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


user traffic - peak during weekends or holidays

traffic spikes during movie releases or special events


1000 users concurrently during peak hours

50 admins/day


10,000 reads / hour during peak

500 writes / hour throughout the day


updates within milliseconds - real time updates


API design

Define what APIs are expected from the system...


user creates an account - POST /v1/users/create_account

user sign-in and authentication- GET /v1/users/authenticate


retrieve movies, showtimes, theatres - GET /v1/movies/#{movie}/listings

retrieve seats available - GET /v1/theatre/#{theatre_name}/seats

user picks seat - POST /v1/theatre/#{theatre}/pick_seats


payments - POST /v1/payments/#{payment_type}

send booking details - POST /v1/booking_details/send_details

send change details - POST /v1/booking_details/send_change_details


user adds movie ratings - POST /v1/movies/#{movie}/add_rating

user updates movie ratings - PUT /v1/movies/#{movie}/update_rating


add movie - POST /v1/movies/add_movie

remove movie - DELETE /v1/movies/#{movie}/remove_movie

update movie - PUT /v1/movies/#{movie}/update_movie


add theatre - POST /v1/theatre/add_theatre

remove theatre - DELETE /v1/theatre/#{theatre}/remove_theatre

update theatre - PUT /v1/theatre/#{theatre}/update_theatre

set showtimes - POST /v1/theatre/#{theatre}/set_showtimes

update showtimes - PUT /v1/theatre/#{theatre}/update_showtimes


within API design, we will also need to consider actions such as rate limiting, caching, authentication, and validation. these are actions that are going to be deferred to the API gateway. we have the option of building our own API gateway or purchasing an out-of-the-box, third party solution. there are pros and cons to each. if we have the man power, building our own api gateway will allow us to be flexible and to tailor the needs specific to our solution whereas a third party solution may not be as flexible, could have less complexity due to less features, but will save on resources.


when rate limiting, we want to consider the read/write usage of users and how they cause traffic spikes during peak hours. since we have 1,000 users concurrently during peak hours with 10,000 reads per hour during the peak, we can assume that each user during peak hours are making 10 reads per hour. because we want to avoid bots hitting us all at once or purchasing all the tickets at once, we want to limit this by using a gradual rate limiting rather than abruptly which can upset users. a sliding window approach will allow for a burst of activity with a specific time interval. we will inform the user when they are rate limited.


in our api gateway, we will also handle authentication and security but we will send our user information to the user service to determine if the user is valid, needs to create an account, or is able to log in. we can send tokens to signify the authentication result. the api gateway will also validate all incoming requests.



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...






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...






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?