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

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