System requirements


Functional:

  • Search movie theatre
  • search movie screens
  • search movie ticket
  • purchase ticket
  • US only



Non-Functional:

  • ACID compliance
  • SQL Database for payments & tickets
  • Availability and eventual consistency



Capacity estimation

  1. Daily Active Users - 10million/month
  2. Throughput - 10,000,000/86200=111 user/sec
  3. Storage
  4. Meta data - 100 GB/month
  5. meta data - 1 TB/Year
  6. Memory
  7. Redis
  8. 100GB data





API design

  • Get
  • User ID
  • Location ID
  • Movie ID
  • Showtime ID
  • Availability
  • Date
  • Time
  • Request
  • User id
  • Location ID
  • Movie ID
  • Showtime ID
  • Book ID
  • Date
  • Time
  • Booking confirmation ID
  • Not available return error code 404



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

  1. DB
  2. Meta Data - Dynamo DB
  3. Booking/Payment - SQL
  4. Movies - Dynamo DB
  5. Queuing
  6. Kafka
  7. to process the request one at a time to avoid concurrency issue

  9. Load Balancer - AWS Elastic load balancing/nginx
  10. distribute the traffic based on the request to app servers using round robin strategy
  11. Elastic load balancing automatically manages the traffic to appropriate servers
  12. API server
  13. Metadata
  14. Movie DB
  15. Booking confirmation DB

  17. Cache
  18. Redis
  19. Add new frequently searched to the list
  20. remove least searched movies
  21. remove movies that has expired time
  22. Horizontal
  23. Hash based sharding
  24. hash all the booking ID with appropriate key for easy look up of the booking confirmation along with the user data
  25. linked hash map
  26. assign a certain time window to hold the reservation for 5 minutes until payment is complete if not remove the reservation hold
  27. Fault Tolerance
  28. Leader
  29. replicate the servers to avoid single failure point of failure
  30. add servers across multiple region for nearest location and eliminate latency
  31. Follower
  32. select the next available server in case of the primary failure
  33. Rate limiter
  34. prevent multiple request from the same client
  35. prevent bot attact









Request flows

  1. Meta DB
  2. Movie DB
  3. movie theatre service
  4. check out service
  5. payment service




Detailed component design

  1. Dynamo DB
  2. Kafka
  3. Kafka
  4. For asynchronous communication between microservices, we will leverage Kafka as a distributed messaging system. Kafka’s fault-tolerant and scalable architecture makes it ideal for handling large volumes of data and ensuring reliable message delivery
  5. we can have multiple producer and consumer request queue based on the FIFO strategy
  6. Horizontal sharding
  7. Hash based sharding
  8. hash all the booking ID with appropriate key for easy look up of the booking confirmation along with the user data
  9. linked hash map
  10. assign a certain time window to hold the reservation for 5 minutes until payment is complete if not remove the reservation hold
  11. eliminates concurrency issue in DB





Trade offs/Tech choices

  1. Dynamo/ CasandraDB
  2. No-SQL
  3. for storing the meta db with additional information as we scale
  4. Dynamo DB automatically scales based on the load
  5. replicates copies across multiple regions
  6. fail safe to different region if one of the server goes down




Failure scenarios/bottlenecks




Future improvements

  1. rate the movies using their profile
  2. review using the profile