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

1. User Interface (UI):
2. Components:
3. Home Page
4. Movie/Event Listings
5. User Authentication & Registration
6. Booking and Payment Interface
7. User Profile Management
8. Application Layer:
9. Components:
10. Ticketing Service:
11. Manages ticket booking, availability, and seat selection.
12. Event Service:
13. Handles event details, trailers, and metadata.
14. User Service:
15. Manages user profiles, authentication, and reviews.
16. Location Service:
17. Handles cinema locations and city details.
18. Booking Engine:
19. Components:
20. Real-time Booking System
21. Seat Selection and Availability Management
22. Integration with Payment Gateway
23. Database Layer:
24. Databases:
25. Relational Database (Users, Bookings, Payment Information)
26. NoSQL Database (Events, Locations, Reviews)
27. Document Store (Search Data, Metadata)
28. Media Database (Trailers, Media Files)
29. Backend Services:
30. Components:
31. Event Scheduler: Manages show timings and schedules.
32. Review Aggregator: Aggregates and displays user reviews.
33. Notification Service: Sends confirmations, reminders, and updates.
34. External Integrations:
35. Components:
36. Payment Gateway Integration
37. Cinema Partner APIs (for real-time seat availability)
38. User Authentication (OAuth, JWT)
39. Infrastructure and Scalability:
40. Components:
41. Load Balancers for distributing traffic
42. Caching (Redis/Memcached) for frequently accessed data
43. Horizontal Scaling with Clusters for databases
44. CDN for media files and trailers
45. Monitoring and Analytics:
46. Components:
47. Logging and Monitoring Tools (e.g., ELK Stack)
48. Analytics Dashboard for User Behavior
49. Performance Metrics for Scalability Assessment
50. Security:
51. Components:
52. SSL/TLS for secure data transmission
53. User Authentication and Authorization Mechanisms
54. Regular Security Audits and Vulnerability Assessments
55. Message Queue (e.g., Kafka):
56. Facilitates asynchronous event processing.
57. Allows decoupling of services, enabling scalability and fault tolerance.
58. Scheduler Service:
59. Manages scheduled jobs, such as updating show timings or sending notifications.
60. Integrates with the message queue for event-driven processing.
61. Search Engine (e.g., Elasticsearch):
62. Indexes and provides efficient searching for events, locations, and metadata.
63. Supports fast and relevant search results for users.
64. Search API:
65. Exposes an API for communication between the application layer and the search engine.
66. Handles search queries and returns results to the user interface.

Request flows

Here is a simple sequence diagram that shows the sequence flow of a user booking a movie ticket.

Detailed component design

For the detailed component diagram, we will discuss the following things,

How do we handle the conflict when multiple users select the same seat while booking a ticket? 

• Conflict Resolution Strategy:
• When multiple users attempt to book the same seat simultaneously, a reservation system can be implemented within the Ticketing Service.
• Use a transactional approach within the database to ensure atomicity. When a user initiates the seat selection process, mark the selected seats as temporarily reserved. If the transaction fails or times out, the seats are released, preventing conflicts.
• A reasonable timeout period could be in the range of a few minutes (e.g., 5-10 minutes).
• Consider the typical time it takes for users to select seats, enter payment information, and confirm the booking.
• During Peak hours this timeout can be reduced to prevent seat hoarding.
• Database Choice Impact:
• A relational database with support for transactions (ACID properties) is essential for this scenario.
• It allows for the atomic execution of operations, ensuring that either all seat reservations are successful or none, preventing inconsistencies.

What are the Background services required and how will they work?

We will need multiple background services for this system, all these services will be scheduled using a Scheduling Service and a Queue (Apache Kafka). Multiple other services can also put messages in this queue to trigger a particular workflow inside these background service. Below are 2 such services.

• Review Aggregation:
• A dedicated Review Aggregator service can periodically fetch and aggregate user reviews from the Review Database.
• The service can use scheduled jobs or event-driven mechanisms to efficiently process and update the aggregated review scores for each movie.
• Notification Service:
• A Notification Service can be responsible for sending notifications to users, such as booking confirmations or reminders.
• It can subscribe to events from the Ticketing Service or Booking Engine, triggering notifications based on booking status changes.
• This service can also be triggered by the User when they want a copy of their booking or payment invoice emailed to them.

What happens when a payment fails for a user?

• Payment Failure Handling:
• If a payment fails during the booking process, the Booking Engine should initiate a rollback to cancel the booking transaction.
• The user should be notified about the payment failure, and the booked seats should be released for others to book.
• Database Choice Impact:
• The choice of a database supporting transactions is critical here. If the payment confirmation and seat booking are part of a single transaction, a failure in any step results in a rollback, maintaining consistency.

Trade-offs/Tech choices

• Simplicity in Current Design:
• Our current database design follows a straightforward approach using a relational database (SQL) for structured data like user information and bookings.
• This simplicity ensures ease of management and straightforward transactions, catering to the immediate requirements of the ticket booking system.
• Potential Hybrid Approach for Enhancement:
• As the platform evolves, a hybrid approach combining SQL and NoSQL databases could be considered for enhanced scalability and flexibility.
• SQL databases can handle transactional data, while NoSQL databases accommodate dynamic and unstructured data like event details and reviews, providing a balanced solution for future scalability.

Future improvements

1. Introduce Caching Mechanism:
2. Implement a distributed caching system to store frequently accessed data, enhancing response times and reducing database load, especially for static information like movie details and city locations.
3. Implement Asynchronous Processing:
4. Introduce message queues for asynchronous processing of tasks such as payment confirmations and notifications, improving system responsiveness and fault tolerance by decoupling time-consuming operations from user interactions.
5. Enhance User Personalization:
6. Integrate a recommendation engine that analyzes user preferences and behavior, providing personalized movie suggestions, thereby enriching the user experience and increasing engagement.
7. Real-time Analytics Dashboard:
8. Develop a real-time analytics dashboard to monitor user behavior, system performance, and booking trends, empowering administrators with valuable insights for data-driven decision-making and continuous system optimization.