System requirements

Functional:

1. User Registration and Login:
2. Users should be able to create an account and log in to the platform.
3. Browse Movies and Shows:
4. Users should be able to browse through a list of movies and showtimes.
5. Users should be able to view details about each movie, such as the plot summary, cast, genre, and trailer.
6. Ticket booking:
7. Users should be able to list different cities where its affiliate cinemas are located.
8. Once the user selects the city, the service should display the movies released in that particular city.
9. Once the user selects a movie, the service should display the cinemas running that movie and its available show times.
10. The user should be able to choose a show at a particular cinema and book their tickets.
11. The service should be able to show the user the seating arrangement of the cinema hall. The user should be able to select multiple seats according to their preference.
12. The user should be able to distinguish available seats from booked ones.
13. Booking information:
14. Users should receive a confirmation of their booking via email or SMS.
15. Users should be able to re-generate their confirmation booking and get it sent via email after booking.
16. Order Management:
17. Admins should be able to view and manage all ticket bookings.
18. Admins should be able to track payments, issue refunds, or cancel bookings.
19. Admins should be able to add new movies, show timings, etc.
20. Reviews and Ratings:
21. Users should be able to rate and review movies they have watched.
22. Other users should be able to view these ratings and reviews to make informed decisions.

Non-Functional:

1. Performance:
2. The system should handle a high volume of simultaneous user requests during peak hours without significant performance degradation.
3. Web pages should load within 3 seconds to ensure a responsive user experience.
4. Scalability:
5. The system should be scalable to accommodate an increasing number of users, movies, and cinemas without a significant decrease in performance.
6. The architecture should support horizontal scaling to add more servers or resources as the user base grows.
7. Reliability:
8. The platform should have a high level of reliability, with an uptime of at least 99.9%.
9. Implement regular backups to prevent data loss in case of system failures.
10. Security:
11. User data, including personal information and payment details, must be encrypted during transmission (SSL/TLS).
12. Availability:
13. Ensure 24/7 availability of the platform, with minimal scheduled downtime for maintenance.
14. Use load balancing and failover mechanisms to distribute traffic and prevent single points of failure.
15. Data Integrity:
16. Implement data validation and integrity checks to prevent errors and inconsistencies in the database.
17. Transactions, especially those related to bookings and payments, should be ACID-compliant.
18. Auditability:
19. Maintain detailed logs of user activities, system events, and errors for auditing and troubleshooting purposes.
20. Logs should be securely stored and accessible only to authorized personnel

Capacity estimation

Assumptions:

• Let us assume 100,000 daily active users
• Peak Hours: during peak hours, there could be a 3x increase in traffic compared to the average. 
• 10,000 events (globally) are listed on the website at any given time.
• 
  

Estimations

• Concurrent Users: Assuming 20% of the DAU are active concurrently, we can estimate around 20,000 concurrent users during peak hours.
• Transactions per Hour: With 20,000 concurrent users making 2 transactions each, the platform needs to handle around 40,000 transactions per hour during peak hours.
• Tickets per Transaction: Assuming an average of 2 tickets per transaction, the platform needs to handle around 80,000 ticket bookings per hour during peak hours.

Storage Estimations: Here are some simple storage calculations

User Data: Considering we have 1,00,000 users, we grow by 40% per year, each user record is 100KB. So, at the end of 5 years,  we will have 1.1M users

Storage Required = 1.1M * 100KB = 1100000 * 100 KB = 110 GB

Media Storage: let’s assume, we have 500 unique events per month that have media video file and each file is 25MB file.

Storage Required = 500 * 12 months * 5 years * 25 MB = 750 GB

API design

API Design

1. get_list_of_cities:
2. Description: Retrieve a list of cities where the platform's affiliate cinemas are located.
3. Input: None
4. Output: List of cities with their respective IDs.
5. get_list_of_events_by_city:
6. Description: Retrieve a list of events (movies or shows) available in a specific city.
7. Input: CityId - ID of the city for which events are to be retrieved.
8. Output: List of events with their details.
9. get_locations_by_city:
10. Description: Retrieve the locations (cinemas) within a specified city.
11. Input: CityId - ID of the city for which locations are to be retrieved.
12. Output: List of locations with their details.
13. get_locations_by_event_and_city:
14. Description: Retrieve the locations where a specific event is being screened in a given city.
15. Input: CityId - ID of the city, EventId - ID of the event.
16. Output: List of locations with their details.
17. get_events_by_location_and_city:
18. Description: Retrieve the events scheduled at a particular location within a specific city.
19. Input: CityId - ID of the city, LocationId - ID of the location.
20. Output: List of events with their details.
21. get_show_timing:
22. Description: Retrieve the show timings for a specific event at a particular location.
23. Input: EventId - ID of the event, LocationId - ID of the location.
24. Output: List of show timings with details.
25. get_available_seats:
26. Description: Retrieve the available seats for a specific event, location, and showtime.
27. Input: EventId - ID of the event, LocationId - ID of the location, ShowtimeId - ID of the show timing.
28. Output: List of available seats with their status.
29. verify_user_selected_seats_available:
30. Description: Verify if the user-selected seats are still available for booking.
31. Input: EventId - ID of the event, LocationId - ID of the location, ShowtimeId - ID of the show timing, Seats - List of selected seat IDs.
32. Output: Confirmation of seat availability.
33. block_user_selected_seats:
34. Description: Temporarily block the user-selected seats to prevent others from booking them.
35. Input: EventId, LocationId, ShowtimeId, Seats.
36. Output: Success/Failure status.
37. book_user_selected_seat:
38. Description: Confirm the booking of the user-selected seats.
39. Input: EventId, LocationId, ShowtimeId, Seats, User Information.
40. Output: Booking confirmation details.
41. get_timeout_for_user_selected_seats:
42. Description: Retrieve the timeout duration for the user-selected seats to complete the booking process.
43. Input: EventId, LocationId, ShowtimeId, Seats.
44. Output: Timeout duration in seconds.

Database design

For the tables required in this design, refer to the class diagram, the list of classes is not exhaustive but this is a good number of tables to start with.

1. Relational Database for User, Booking, and Payment Data:
2. Reasoning: User data and booking information require strong consistency and relational structure to maintain data integrity and enforce ACID properties.
3. Database Type: Relational Database (e.g., PostgreSQL, MySQL).
4. CAP Theorem Focus: Consistency is prioritized to ensure accurate and reliable user information and booking details.
5. NoSQL Database for Event, Location, Reviews, and Comments Data:
6. Reasoning: Event details and location information may vary and evolve, requiring a flexible schema and scalability, making NoSQL databases suitable.
7. Database Type: NoSQL Database (e.g., MongoDB, Cassandra).
8. CAP Theorem Focus: Partition tolerance and availability are crucial to handle potential changes in data structure and support scalable operations.
9. Document Store for Search Data:
10. Reasoning: Search data benefits from a document-oriented storage approach, enabling fast and efficient retrieval of movie and event-related information.
11. Database Type: Document Store (e.g., Elasticsearch).
12. CAP Theorem Focus: Availability is emphasized for quick and responsive search capabilities.
13. Media Database for Media Files:
14. Reasoning: Multimedia files, such as movie trailers, require efficient storage and retrieval, making media databases suitable for this purpose.
15. Database Type: Media Database (e.g., Amazon S3, MongoDB with GridFS).
16. CAP Theorem Focus: Emphasis on Availability and Partition Tolerance to ensure media files are accessible and retrievable.
17. Key-Value Store for Metadata and Quick Lookups of popular events:
18. Reasoning: Metadata and quick lookups can benefit from a key-value store for simplicity and fast access to specific information.
19. Database Type: Key-Value Store (e.g., Redis).
20. CAP Theorem Focus: Emphasis on Availability and quick lookups, while still maintaining Partition Tolerance.

Data Partitioning Strategy:

• Best Strategy: Hash-Based Partitioning.
• Reasoning: Hash-based partitioning ensures even distribution of data and avoids hotspots, which is essential for a system dealing with various entities like users, events, and bookings. It provides a balanced approach to data distribution across partitions.

Regional or Geographical Partitioning:

• Applicability: Consider regional or geographical partitioning for tables that have location-based data, such as Events or Locations.
• Reasoning: Regional partitioning can enhance performance by allowing the system to focus on a specific geographical region when serving requests related to events, locations, or cinemas. This is especially useful for platforms that have a global presence.

Partitioning Adjustments:

• Applicability: Required as specific tables grow disproportionately.
• Reasoning: Periodically reassess the partitioning strategy, especially for tables like Bookings or Events, and adjust as needed to maintain optimal data distribution and prevent hotspots.

Sharding Strategy:

• Best Strategy: Range-Based Sharding for Events or Bookings, Hash-Based Sharding for Users or Reviews.
• Reasoning:
• Range-Based Sharding: Suitable for tables where data can be logically grouped, such as Events based on date ranges or Bookings based on booking IDs.
• Hash-Based Sharding: Ideal for tables where uniform distribution of data is crucial, preventing hotspots. For example, Users or Reviews tables can benefit from hash-based sharding.

Scaling Strategy

• Horizontal Scaling:
• Applicability: Essential as the system grows and experiences increased demand.
• Reasoning: With a large user base and varying levels of activity, horizontal scaling by adding more database nodes or servers helps distribute the load and handle increased concurrency effectively.

• Read/Write Separation:
• Applicability: Suitable when there is a clear distinction between read and write workloads.
• Reasoning: By directing read operations to read replicas and write operations to the primary database, the system can efficiently handle more concurrent users and improve overall responsiveness.

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?