Design Ticketmaster

What is Ticketmaster?

Ticketmaster is a large-scale ticketing platform that lets users browse events, search for tickets, view seating charts, reserve and purchase tickets, and manage their bookings. It is similar to BookMyShow in India. Other ticketing systems, such as airline and hotel reservation platforms, follow a similar pattern.

Real-time seat allocation under massive surge traffic is what makes systems like Ticketmaster unique. By understanding Ticketmaster, you can tackle interview questions for similar systems, since the core design challenges—real-time inventory, concurrency, high demand handling, and reservations—remain the same.

Functional Requirements

Core (Interview Focussed)

• Real-time Seat Availability: Show accurate, up-to-the-second inventory across all users.
• Ticket Reservation & Purchase: Handle temporary holds, prevent double-booking, and finalize payments reliably.
• High-Demand Event Handling: Support massive surges when tickets go on sale.
• Search: Users should be able to browse and search for events.

Out of Scope

• Admin: Adding/updating events
• User accounts and login
• Ticket cancellation / refunds
• Notifications (Emails, App Push, SMS)
• Payment gateway integration

Non-Functional Requirements

Core (Interview Focussed)

• Low latency search: Users should get search results quickly, even under high load.
• High availability: The system should remain accessible during peak traffic.
• Consistency: Ensure no double booking or overselling of tickets.

Out of Scope

• Business continuity and disaster recovery (BCDR)
• GDPR and other data privacy regulations

💡 Interview Tip: Focus on low latency, high availability, and consistency. Interviewers care most about real-time inventory, concurrent reservations, and peak traffic.

Core Entities

💡 Interview Tip: Focus on Tickets, Reservations, and Bookings as they drive concurrency, real-time inventory, and high-demand handling.

Core APIs

Event Discovery

• GET /events?date=&location=&category=&page=&limit= – Returns a paginated list of events
• GET /events/{event_id} – Get details of a single event

Ticket Availability

• GET /events/{event_id}/tickets?section=&row=&price_range= – List available tickets
• GET /tickets/{ticket_id} – Get details of a specific ticket

Reservation & Booking

• POST /tickets/reserve { user_id, event_id, ticket_ids[], hold_duration } – Temporarily hold tickets
• POST /tickets/purchase { reservation_id, payment_reference } – Confirm reservation and complete purchase
• GET /bookings/{booking_id} – Retrieve booking confirmation and ticket details

High-Level Design

Key Components

• Client / Frontend: Web or mobile app for browsing events, seating charts, and purchasing tickets
• API Gateway: Routes requests, handles throttling, and load balancing
• Event Service: Manages event details, venue info, and seat availability queries
• Booking Service: Handles ticket inventory, reservations, purchases, cancellations, and prevents double-booking
• Cache / In-Memory Store: Speeds up seat availability lookups and handles temporary reservations
• Database / Persistent Storage: Stores events, tickets, bookings, and user data
• Elasticsearch: Provides fast, scalable search and filtering capabilities for events, tickets, and venues
• Payment Service: Processes payments (out of scope)

Mapping Core Functional Requirements to Components

💡 Interview Tip: Focus on Ticket Service, Booking Service, and Cache; other components can be simplified.

TicketMaster Architecture

Data Modeling

💡Design Tips

• Normalize static data (events, venues) to reduce duplication
• Keep ticket and reservation tables highly optimized for reads/writes
• Partition tickets by event_id for concurrency scalability
• Use composite indexes on (event_id, seat_number) to quickly find availability
• Use Elasticsearch for fast search and filtering while DB remains source of truth
• Update Elasticsearch asynchronously to reduce DB load
• Use Redis distributed locks for temporary ticket reservations to prevent double-booking

Data Flow & Component Interaction

This diagram illustrates the data flow and component interaction when a user searches for events, selects seats, and completes a ticket purchase in a Ticketmaster-like system. It highlights the key components that ensure real-time seat availability, concurrency control, and high scalability.

Event Search & Discovery

• The user initiates a search from the frontend.
• The API Gateway routes the request to the Event Service, which queries Elasticsearch for events filtered by name, date, location, category, and price range.
• Elasticsearch provides low-latency, paginated results, which the frontend displays to the user.
• Note: The database is not queried directly here, keeping search operations fast and scalable.

Seat Selection & Temporary Reservation

• The user selects seats to reserve.
• The Booking Service first attempts to acquire a Redis distributed lock on the selected tickets, preventing double-booking across multiple users.
• Availability is checked against Redis cache or the primary database, which serves as the source of truth.
• Once available, the tickets are temporarily reserved, and a TTL-based lock ensures that tickets are automatically released if the user abandons the checkout process.
• A reservation ID is returned to the frontend for confirmation.

Ticket Purchase & Booking Confirmation

• The user confirms the purchase using the reservation ID.
• The Booking Service validates the reservation and Redis lock.
• Tickets are marked as sold in the database, and the lock is released.
• Elasticsearch is asynchronously updated to reflect the current ticket availability in search results.
• A booking confirmation is sent back to the user.

Key Design Highlights

• Redis Distributed Lock: Ensures atomicity and prevents double-booking under high concurrency.
• Cache + Database: Cache accelerates availability checks; the database remains the source of truth.
• Elasticsearch: Handles fast search/filter queries for the frontend, reducing database load.
• Asynchronous Updates: Elasticsearch updates are performed asynchronously to maintain low-latency user interactions without compromising data consistency.

This flow guarantees real-time seat availability, high throughput during peak demand, and consistent booking state, making it ideal for Ticketmaster-like platforms where millions of users may compete for the same seats simultaneously.

Caching & Performance Optimization

Caching is critical for high-demand systems like Ticketmaster.

Use Cases

• Event search: Store event lists and filters in read-optimized cache or Elasticsearch.
• Seat availability: Maintain real-time availability in in-memory store.
• Temporary reservations: Use TTL-based cache entries to handle holds.

Techniques

• Write-through / write-behind cache: Keep cache consistent with the database.
• Partitioned cache by event_id: Reduces lock contention.
• Bloom filters: Quickly check if a ticket is available before querying the database.
• Queue-based concurrency control: For flash sales, serialize requests for hot events.

💡 Interview Tip: Be ready to discuss trade-offs between consistency, latency, and availability. Refer to the CAP theorem for further reading.

Handling Concurrency & Preventing Double Booking

Concurrency is the most critical challenge in Ticketmaster-like systems.

Challenges

• Multiple users trying to reserve the same seat simultaneously.
• Temporary reservations expiring while another user attempts booking.

Solutions

• Optimistic Locking:
  • Each ticket row has a version number.
  • When updating ticket status, check that the version hasn’t changed.
  • If conflict occurs, retry or fail gracefully.
  • Best for low to moderate contention scenarios.
• Pessimistic Locking:
  • Lock ticket row during reservation/purchase.
  • Guarantees no double-booking but can reduce throughput under high load.
• Atomic Operations in Cache:
  • Use Redis SETNX / Lua scripts to atomically reserve tickets.
  • Ensures fast, distributed locks without hitting the database every time.
• Queue-Based Reservation Handling:
  • For hot events, enqueue requests in Kafka / RabbitMQ.
  • Process sequentially to prevent race conditions.
  • Sacrifices a bit of latency for strong consistency under surge traffic.

💡 Interview Tip: Be ready to explain trade-offs: speed vs consistency, optimistic vs pessimistic locking, cache vs database as the source of truth.

Scaling for Peak Load

Ticketmaster must handle flash sales, often millions of requests in seconds.

Strategies

• Horizontal Scaling:
  • Scale API Gateway, Event Service, Booking Service horizontally.
  • Use load balancers to distribute traffic evenly.
• Database Sharding / Partitioning:
  • Partition Tickets and Reservations by event_id.
  • Allows parallel writes without conflicts.
• Read Replicas & Caching:
  • Search-heavy queries served from read replicas or in-memory caches.
  • Reduces load on primary database.
• Queueing & Rate Limiting:
  • Use queues for processing reservations sequentially.
  • Rate-limit requests per user or per IP to prevent abuse.
• CDN & Edge Caching:
  • Serve static content (event pages, images) from CDNs.
  • Reduces latency for users across geographies.
• Auto-Scaling:
  • Dynamically spin up instances based on traffic patterns (cloud-native solution).

💡 Interview Tip: Highlight trade-offs between latency, cost, and availability. Interviewers value candidates who can discuss real-world scaling challenges.

Optional Enhancements & Trade-offs

Even though these are not core requirements, discussing them shows advanced system design thinking and helps in interviews.

• Seat Map Precomputation & Rendering
  • Enhancement: Precompute seat availability per section or row for faster UI rendering.
  • Benefit: Improves frontend responsiveness, especially during high-demand events.
  • Trade-off: Requires extra storage and synchronization with DB and cache; may introduce slight lag in real-time updates.
• Dynamic Pricing
  • Enhancement: Adjust ticket prices dynamically based on demand, time, or popularity.
  • Benefit: Maximizes revenue for hot events.
  • Trade-off: Adds complexity in consistency; requires near real-time analytics; users may see rapidly changing prices.
• Analytics & Metrics
  • Enhancement: Track popular events, conversion rates, sold-out sections, and reservation expirations.
  • Benefit: Enables data-driven decisions for marketing, promotions, and system optimization.
  • Trade-off: Requires additional data pipelines and storage; analytics queries may impact DB performance if not separated.
• Event Recommendations
  • Enhancement: Provide personalized suggestions using ML models based on user behavior or past bookings.
  • Benefit: Increases engagement and ticket sales.
  • Trade-off: Adds complexity with ML pipelines, feature storage, and real-time serving.
• Search Optimization
  • Enhancement: Use Elasticsearch aggregations, faceted search, and caching for advanced filtering.
  • Benefit: Extremely fast search and filtering experience for users.
  • Trade-off: Requires asynchronous updates and careful cache invalidation to prevent stale availability.

Trade-off Summary

• Enhancements improve performance, revenue, and UX, but introduce complexity, potential eventual consistency, and higher operational cost.
• In interviews, clearly justify each enhancement with its benefits and associated challenges.

Frequently Asked Questions (FAQ)

How do Redis distributed locks help in ticket reservations?

Redis locks prevent double-booking across distributed systems. When a user selects tickets, the Booking Service acquires a lock on those ticket IDs. The lock has a TTL, ensuring that tickets are automatically released if the user abandons checkout.

Why use Elasticsearch in the design?

Elasticsearch provides fast search and filtering for events, tickets, and venues. It offloads read-heavy queries from the database and allows advanced filtering by date, location, price, or category. The database remains the source of truth for ticket availability.

How do we prevent race conditions during high-demand events?

• Optimistic locking: version numbers on ticket rows, retry on conflict.
• Pessimistic locking: lock rows during reservation.
• Atomic cache operations: Redis SETNX or Lua scripts.
• Queue-based handling: Enqueue requests in Kafka/RabbitMQ for hot events.

How is scaling handled for flash sales?

• Horizontal scaling of API Gateway, Event Service, and Booking Service.
• Database sharding / partitioning by event_id.
• Read replicas and caching for search-heavy queries.
• Queueing and rate-limiting to prevent overload.
• CDN & edge caching for static content.
• Auto-scaling cloud instances based on traffic.