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. amount
8. booking ID
9. No-sQL DB schema
10. user ID
11. first name
12. last name
13. email
14. phone number
15. create one more table to merge
16. user id
17. booking ID

High-level design

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

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