Bird
Raised Fist0

Design a Ticketing System like BookMyShow - Seat Locking, Concurrency, Payment

HLDhardInterview freq: high
Choose your preparation mode4 modes available
ArchitectureTraceChallenge
🏗️
Design a Ticketing System like BookMyShow - Seat Locking, Concurrency, Payment
High-scale ticket booking with strong concurrency control, seat locking, and payment integration
hardE-Commerce and PaymentsFreq: high
Prerequisites:IdempotencyACID Transactions
⚙️
Functional Requirements
  • Users can browse events and select seats in real-time with seat availability shown
  • Seat locking mechanism to temporarily reserve seats during booking to prevent double booking
  • Concurrent booking requests handled with strong consistency to avoid overselling
  • Integration with payment gateway supporting idempotent payment processing and rollback on failure
  • Booking confirmation with ticket generation and notification to user
  • Admin interface for event and seat inventory management
📊
Non-Functional Requirements
  • Support 50 million daily active users (DAU) with peak concurrency of 1 million simultaneous bookings
  • System availability of 99.99% uptime to ensure booking reliability
  • End-to-end booking latency under 200ms P99 to provide smooth user experience
  • Seat lock timeout configurable, default 2 minutes, to release seats if payment not completed
  • Data durability with multi-region replication and ACID guarantees for booking transactions
❓
Clarifying Questions to Ask
  • What is the maximum number of seats per event and per venue?
  • What is the expected peak QPS for booking requests during popular events?
  • Is eventual consistency acceptable for seat availability display or must it be strongly consistent?
  • What payment gateways and methods need to be supported?
  • Are partial bookings (booking some seats but not all requested) allowed?
  • What is the expected failure rate and retry policy for payment processing?
Out of Scope
✗ Event discovery and recommendation algorithms
✗ User profile management and authentication
✗ Marketing campaigns and promotions
✗ Physical ticket printing and delivery logistics
📌
Assumptions
  • 50 million DAU with average 20 booking attempts per user per day
  • Average booking request size 200 bytes including user, event, seat info
  • Peak booking concurrency 1 million simultaneous seat lock requests
  • Retention of booking data for 1 year with replication factor 3
⚡
QPS Calculation
write qps50M users × 20 bookings/day ÷ 86400 sec ≈ 11,574 writes/sec
peak write qpsPeak concurrency 1M seat lock requests over 2 minutes lock time → 1M ÷ 120 sec ≈ 8,333 writes/sec
read qpsAssuming 5 reads per write for seat availability and event browsing → 11,574 × 5 ≈ 57,870 reads/sec
💾
Storage Estimate
daily storage11,574 writes × 200 bytes = 2.31 MB/day
annual storage2.31 MB × 365 days = 843.15 MB/year
with replication843.15 MB × 3 replicas = 2.53 GB/year
🖥️
Server Estimate
api serversAssuming 1000 req/sec per server → 12 servers for writes + 58 servers for reads = 70 servers total
db serversUsing Cassandra with 100K writes/sec capacity per node → 1 node sufficient for writes, 3 nodes for replication and availability
🏗️
Architecture Diagram
Architecture Diagram
          +-------------+
          |  User App   |
          +------+------+
                 |
          +------+-------+
          |  API Gateway |
          +------+-------+
                 |
    +------------+-------------+
    |                          |
+---v---+                  +---v---+
| Seat  |                  |Payment|
| Lock  |                  |Service|
|Service|                  +---+---+
+---+---+                      |
    |                          |
    |                          |
    |                   +------+------+
    |                   | Payment     |
    |                   | Gateway     |
    |                   +-------------+
    |
    |
+---v---+
|Booking|
|Service|
+---+---+
    |
    |
+---v---+
|Cassandra|
|Cluster  |
+---------+
🧩
Components
API Gateway
Entry point for all client requests, routes to appropriate services, handles rate limiting and authentication
Why thisEnvoy proxy supports high throughput, dynamic routing, and observability for microservices
Why notNginx lacks native service discovery and dynamic routing needed for microservice scale
Seat Lock Service
Manages seat locking with TTL to prevent double booking during payment window
Why thisRedis with TTL and Lua scripts provides atomic seat lock/unlock with sub-millisecond latency and automatic expiry
Why notMemcached lacks atomic operations and TTL-based eviction needed for consistent seat locking
Booking Service
Finalizes booking by writing confirmed seats and user info to persistent storage with ACID guarantees
Why thisApache Cassandra provides linear write scalability and tunable consistency for high throughput booking writes
Why notPostgreSQL requires complex manual sharding and cannot handle 10K+ writes/sec without bottlenecks
Payment Service
Handles payment processing, idempotency, and rollback coordination with booking service
Why thisCustom microservice with idempotency keys and two-phase commit pattern ensures exactly-once payment processing
Why notDirect synchronous calls to payment gateway risk inconsistent state on network failures
Payment Gateway
External third-party payment processor for credit card, UPI, and wallet payments
Why thisIndustry-standard PCI-compliant gateway with retry and webhook support for asynchronous payment confirmation
Why notBuilding in-house payment gateway is out of scope and risks compliance issues
Cassandra Cluster
Stores booking data, seat inventory, and user booking history with high availability and replication
Why thisCassandra's masterless architecture and tunable consistency enable high write throughput and fault tolerance
Why notMySQL master-slave replication causes write bottlenecks and single point of failure
🔄
Data Flow
1
User App → API Gateway
User selects event and seats, sends booking request
Request includes event_id, seat_ids, user_id
2
API Gateway → Seat Lock Service
Request to lock selected seats with TTL
Atomic check-and-set via Redis Lua script to prevent double locking
3
Seat Lock Service → API Gateway
Return lock success or failure
If failure, user prompted to select different seats or retry

Practice

(1/5)
1. A system requires 99.99% availability for a critical service that must tolerate a single data center failure without downtime. Which component is most appropriate to achieve this?
easy
A. Deploy active-active multi-region clusters with automatic failover
B. Rely on local in-memory caches to serve requests during outages
C. Use a single-region relational database with synchronous replication
D. Use a single data center with redundant power and network equipment

Solution

  1. Step 1: Understand availability target and failure domain

    99.99% availability requires tolerating entire data center failure without downtime, which single-region setups cannot guarantee.

  2. Step 2: Evaluate options for multi-region failover

    Active-active multi-region clusters with automatic failover provide seamless continuity, unlike local caches or single-region redundancy.

  3. Final Answer:

    Option A -> Option A

  4. Quick Check:

    Multi-region active-active clusters -> tolerate data center failure [check]
Hint: Multi-region active-active -> survive data center failure [check]
Common Mistakes:
2. In the request flow for a nearby search, at step 4 the Quadtree component receives a query bounding box. What does the Quadtree do at this step?
easy
A. It returns all businesses within the bounding box without further filtering
B. It converts the bounding box into Geohash prefixes and queries a key-value store
C. It recursively traverses nodes intersecting the bounding box to collect candidate locations
D. It sends the bounding box to a full-text search engine for keyword filtering

Solution

  1. Step 1: Understand Quadtree traversal

    At step 4, the Quadtree recursively visits nodes overlapping the bounding box to efficiently narrow down candidate locations.

  2. Step 2: Eliminate other options

    It returns all businesses within the bounding box without further filtering is incorrect because Quadtree does filtering, not a full scan. It converts the bounding box into Geohash prefixes and queries a key-value store describes Geohash usage, not Quadtree. It sends the bounding box to a full-text search engine for keyword filtering is unrelated to spatial indexing.

  3. Final Answer:

    Option C -> Option C

  4. Quick Check:

    Quadtree recursively traverses nodes intersecting query box [check]
Hint: Quadtree recursively visits nodes overlapping query bounding box [OK]
Common Mistakes:
3. Without a distributed consensus system (like Paxos or Raft) coordinating leader election, what exactly breaks in a system designed for 99.999% availability?
medium
A. Clients receive stale data but system continues operating normally
B. Multiple nodes may believe they're leader simultaneously, causing conflicting writes and data corruption
C. The system automatically fails over to a backup leader without downtime
D. Leader election happens instantly with no impact on availability

Solution

  1. Step 1: Role of distributed consensus in leader election

    Consensus protocols ensure exactly one leader at a time, preventing split-brain scenarios.

  2. Step 2: Consequences of missing consensus

    Without consensus, multiple nodes may act as leader simultaneously, causing conflicting writes and data corruption, breaking availability guarantees.

  3. Final Answer:

    Option B -> Option B

  4. Quick Check:

    No consensus -> split-brain -> conflicting writes -> data corruption [check]
Hint: No consensus -> split-brain -> conflicting writes break availability [check]
Common Mistakes:
4. If the Kafka topic used for driver location updates is deleted accidentally, what is the immediate failure observed in the system?
medium
A. Driver location updates are lost permanently with no retry, causing stale driver positions
B. The system automatically switches to a backup topic with no data loss
C. Driver apps crash due to inability to send location updates
D. Matching service blocks waiting for location updates, causing request timeouts

Solution

  1. Step 1: Understand Kafka topic role

    Kafka topic buffers and streams driver location updates to downstream services.

  2. Step 2: Trace failure impact

    Deleting the topic causes producer writes to fail silently or drop messages; no automatic backup switch; driver apps continue sending but updates are lost; matching service receives stale data but does not block.

  3. Final Answer:

    Option A -> Option A

  4. Quick Check:

    Kafka topic deletion causes permanent loss of location updates [check]
Hint: No Kafka topic means lost updates, no automatic failover [check]
Common Mistakes:
5. At 10x scale, which component in a saga-based event-driven system is most likely to fail first due to stateful bottlenecks, and why?
hard
A. The saga coordinator, because it maintains in-memory state per saga and cannot shard easily
B. The message broker, because partition count limits throughput and ordering guarantees
C. The database, because increased writes cause lock contention on outbox tables
D. The event relay service, because network bandwidth saturates before CPU

Solution

  1. Step 1: Identify stateful bottleneck

    The saga coordinator holds per-saga state in memory, limiting horizontal scaling and sharding.

  2. Step 2: Compare other components

    Message brokers scale with partitions; DB scales with sharding; relay is stateless and network-bound.

  3. Final Answer:

    Option A -> Option A

  4. Quick Check:

    Saga coordinator's in-memory state limits scaling first [check]
Hint: Stateful saga coordinator limits scaling before stateless components [check]
Common Mistakes:
Recommended

Ready to prove it?

Pass the test and this pattern moves unknown strong while earning +1 Grip toward your certificate.

10 questions~5 mineasy hard