System requirements


Functional:

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



Non-Functional:

  • ACID compliance
  • SQL Database for payments & booking confirmation
  • Availability and eventual consistency
  • No-SQL Database
  • to store meta data



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

  1. SQL DB schema
  2. User ID
  3. movie name
  4. number of tickets
  5. show date
  6. show time
  7. seat number
  8. amount
  9. booking ID
  10. No-sQL DB schema
  11. user ID
  12. first name
  13. last name
  14. email
  15. phone number
  16. create one more table to merge
  17. user id
  18. booking ID
  19. seat number


High-level design


Non-Functional requirement -

  1. Data Base
  2. Meta Data - Dynamo DB
  3. user profile
  4. Booking/Payment - SQL
  5. link user profile against the booking confirmation
  6. Movies - Dynamo DB
  7. search movies based on the state/city or zip code
  8. Queuing
  9. Kafka
  10. sequence the user request one at a time to based on first come basis

  12. Load Balancer - AWS Elastic load balancing/nginx
  13. distribute the traffic based on the request to app servers using round robin strategy
  14. Elastic load balancing automatically manages the traffic to appropriate servers
  15. API server
  16. Metadata
  17. Movie DB
  18. Booking confirmation DB
  19. Cache
  20. Redis
  21. Add new frequently searched to the list
  22. remove least searched movies
  23. remove movies that has expired time
  24. Horizontal
  25. Hash based sharding
  26. hash all the booking ID with appropriate key for easy look up of the booking confirmation along with the user data
  27. linked hash map
  28. assign a certain time window to hold the reservation for 5 minutes until payment is complete if not remove the reservation hold
  29. Fault Tolerance
  30. Leader
  31. replicate the servers to avoid single failure point of failure
  32. add servers across multiple region for nearest location and eliminate latency
  33. Follower
  34. select the next available server in case of the primary failure
  35. Rate limiter
  36. prevent multiple request from the same client
  37. prevent bot attack
  38. Security
  39. user authentication through registration using user id as email along with password
  40. lock the account if the password fails after 5 attempts
  41. Metrics & analytics logs
  42. Datadog/Grafana - We can pull logs from all the services and monitor them in a dashboard

Functional requirement

  1. Search movies based on the location - state/city or zip code
  2. Reservation count/Seat selection
  3. user can reserve a total of 10 seats at one time
  4. seat selection -
  5. select even number of seats in the count of 2
  6. select in a available sequence first if not available then select randomly
  7. Booking & payment confirmation
  8. Ticket will wait in the check out queue for 5 minutes until the payment is made
  9. Once the payment is made the ticket is confirmed and a booking id is generated against it









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. if one of the queue fails then take the last failed request to a different queue and start processing from there based on the time
  7. Horizontal sharding
  8. Hash based sharding
  9. hash all the booking ID with appropriate key for easy look up of the booking confirmation along with the user data
  10. linked hash map
  11. assign a certain time window to hold the reservation for 5 minutes until payment is complete if not remove the reservation hold
  12. eliminates concurrency issue in DB
  13. Payment Gateway
  14. for credit card payments we can have third party service provider such as stripe/adyen for security reasons and confirm the payment






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. Bulk booking
  2. Refund
  3. different payment methods - apple/google
  4. rate/review the movies using the profile