1. Overview

Develop a scalable event ticketing platform similar to Ticketmaster that allows users to browse, search, and purchase tickets for various events.

The system will handle high-concurrency scenarios during popular event sales while maintaining data consistency and providing a seamless user experience.

Key features:

• Real-time ticket inventory management
• High-concurrency ticket purchasing system
• Advanced event search and filtering
• Secure payment processing
• Real-time notifications for ticket availability and purchase confirmations
• Fair queueing system for high-demand events

2. System Architecture

2.1. Core components

• Client: Represents the end-user interface, a web application, interacting with the platform.
• Load Balancer / API Gateway: Manages incoming client requests and distributes them across services. It also supports Server-Sent Events (SSE) or WebSocket protocol for real-time updates to clients.
• Auth Service: Manages user's information, supports authentication and authorization.
• Event Service: Manages events, likely handling operations like event creation, updates, and retrieval. It communicates directly with the database.
• Event Search Service: Facilitates search functionality, enabling users to find events. This service uses Elasticsearch to quickly retrieve and index data for fast searching. Changes in the database are propagated to Elasticsearch through Kafka.
• Booking Service: Manages booking-related actions, such as creating and updating bookings.
• Database and Cache: Stores event and booking data. The cache (e.g., Redis) likely helps speed up data retrieval and reduce database load.
• CDC (Change Data Capture) & Kafka: Captures changes in the database (CDC) and sends them through Kafka to synchronize with other services like Elasticsearch.
• Message Queue: Buffers messages related to booking requests, allowing asynchronous processing and helping handle high traffic or surges.
• Booking Consumer: Consumes booking messages from the queue and processes them, interacting with both the booking service and Stripe.
• High Demand Booking Consumer: Manages real-time, high-demand bookings, possibly with priority processing to handle limited availability events. (first come first serve)
• Stripe (Payment Gateway): Manages payment transactions for bookings, ensuring secure and reliable processing of payments.

3. Functional Requirements

3.1. User Management

• Registration & Authentication
  • Register with email/password
  • Login/logout functionality
  • Password reset (Optional)
• User Types
  • Customer: Browse and book tickets
  • Merchant: Create and manage events (Optional)
  • Admin: System management
• Profile
  • View/edit basic information
  • View booking history

3.2. Event Management

• Event Details
  • Basic info: name, description, date/time, venue, location
  • Ticket types and pricing
  • Available ticket quantity
  • Optional seating layout
• Event Status
  • Available: Open for booking
  • Reserved: Temporarily held
  • Booked: Successfully purchased
  • Sold Out: No tickets available

3.3. Search Functionality

• Search by
  • Event name
  • Category
  • Date range
  • Location
  • Price range
• Features
  • Filter and sort results
  • Auto-suggestions (optional)

3.4. Booking System

• Reservation Process
  • Select available tickets
  • Hold tickets for 5 minutes
  • Complete payment
  • Receive confirmation
  • Shopping Cart (Optional)
  • Add/remove tickets
  • View total cost
• Payment
  • Integration with payment gateway (Stripe or any Payment Service Provider you prefer)

3.5. High-Demand Event Handling

• Virtual Waiting Room
  • FIFO queue for popular events
  • Show queue position
  • Notify when it's user's turn
• Reservation Rules
  • One ticket can be booked by only one user
  • 5-minute reservation timeout
  • Auto-release of unpaid reservations
  • Next person in queue gets opportunity to book

3.6. Real-time Features

• Availability Updates
  • Show available vs booked tickets
  • Display reservation timer
  • Update queue position
  • Optional notification system

3.7. Key Business Rules

• No double bookings allowed
• Reservations expire after 5 minutes
• First-come-first-served for waiting list
• Clear distinction between available and booked tickets
• Real-time event seat updates (Optional)

4. Non-Functional Requirements

• The system should prioritize high availability for searching & viewing events, but should prioritize strong consistency for booking events (no double booking)
• The system should be scalable and able to handle high throughput in the form of popular events (10 million DAU)
• The system should have low latency search (< 500ms)
• The system is read heavy, and thus needs to be able to support high read throughput.
• QPS (Query per second) = 10 Milliion users / (60 * 60 * 24) =  100 QPS approximately
• Peak QPS = 2 * QPS = 200

5. Out of scope

• Security requirements around user data protection and secure payment processing
• The system should be fault tolerant
• Reliability requirements for fault tolerance, error handling, and backup/recovery
• The system should handle reconciliation for all the payments and refund.
• The system should be well tested and easy to deploy (CI/CD pipelines)
• Advanced reporting and business intelligence features
• Mobile app development (the initial version will be web-based)
• Internationalization and multi-language support
• Livestreaming or virtual event capabilities
• Real time notification system

6. Deliverables

• Source code in a Git repository
• Design documentation (System diagram, database design, sequence diagram, ...)
• API documentation
• Test cases and results
• Project presentation

7. Learning Objectives

• Microservices architecture
• Setting up the real server on VMs (Virtual Machine)
• CI/CD (Applying Jenkins and Pasta/nDeploy)
• Distributed systems concepts
• High-concurrency handling
• Caching strategies
• Near real-time data processing
• Search engine integration (Elasticsearch, CDC, ...)
• Intergrate with third-party api (Stripe payment)