Design a Ticketing System (BookMyShow) 🎟️

A ticketing system is a high-concurrency platform that allows users to browse, book, and manage tickets for massive events like concerts, sports, and movies.

🚀 Introduction

A modern ticketing system must handle extreme traffic spikes (flash sales) while ensuring atomic seat allocation to prevent double-booking.

• Real-time Availability: Instant feedback on seat status.
• Secure Transactions: Hard transactional guarantees for payments.
• High Concurrency: Handling hundreds of thousands of users simultaneously during "Big Concert" releases.

📋 Requirements

Functional Requirements

• Browse & View: Search for events, venues, and view real-time seat maps.
• Book/Reserve: Lock a seat temporarily (e.g., 5-10 mins) during checkout.
• Payment & Confirmation: Secure checkout and instant notification (SMS/Email).
• Admin Portal: Tools for organizers to setup venues and pricing.

Non-Functional Requirements

• High Availability: Service must stay up during peak sell-out events.
• Strong Consistency: Absolute requirement to avoid double-booking.
• Low Latency: High-speed seat locking and availability checks.
• Auditability: Complete logs for every transaction and seat movement.

📐 High-Level Architecture

The system follows a microservices pattern to decouple heavy read traffic (browsing) from transactional write traffic (booking).

🔑 Key Design Decisions

1. Concurrency Control (Double-Booking Prevention)

This is the most critical part of the system.

• Optimistic Locking: Uses a version number in the DB. Best for lower contention.
• Pessimistic Locking: Locks the specific row in the DB (e.g., SELECT FOR UPDATE). More reliable for extreme contention but can lead to performance bottlenecks.
• Redis Distributed Locks: Many modern systems use Redis distributed locks (Redlock) or TTL-based keys to hold a seat for exactly 5 minutes.

2. Seat Hold Timeout

When a user selects a seat, it enters a LOCKED state.

• Logic: Store seat_id:user_id in Redis with a TTL of 300 seconds.
• Result: If the user doesn't pay in 5 minutes, the key expires, and the seat automatically returns to AVAILABLE.

3. CQRS Pattern

Split your data model:

• Read Side: High-speed seat maps served from Redis/Elasticsearch.
• Write Side: Transactional bookings handled by a relational database (PostgreSQL) for ACID compliance.

🛠️ API Design

Event Management

• GET /events: Fetch listings with pagination/filtering.
• GET /events/{eventId}: Detailed view of venue and available seats.

Booking Workflow

• POST /bookings: Initial request to lock seats.

{
  "eventId": "EV-101",
  "userId": "USR-7",
  "seatIds": ["A12", "A13"]
}

• Response: 201 Created with a bookingId and a timeout timestamp.

🏗️ The Final Design

4. Idempotency Keys for Payments

To prevent duplicate charges, every payment request must include a unique idempotency_key generated by the client. The server checks this key before processing to ensure it never charges the same transaction twice.

5. Audit Logging & Fraud Detection

• CDC (Change Data Capture): Stream every database change to a dedicated Audit service via Kafka.
• ELK Stack: Centralize logs for real-time monitoring and suspicious activity detection (e.g., bot detection during flash sales).

📊 Scale Estimation

• DAU: ~1 Million
• Peak Load: Up to 2,000 bookings per second during major "Star Concert" releases.
• Concurrent Users: ~100,000 during peak events.
• DB Write Pressure: Use sharding on eventId or venueId to distribute the write load.
• Async Processing: Offload Emails, SMS, and Audit logging to Kafka to keep the core booking flow low-latency.

💡 Top Interview Questions