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
45 min · senior
senior

You are designing a ticket booking platform serving 50 million daily active users with peak concurrency during popular event launches. The system must handle real-time seat locking to prevent double bookings, ensure strong concurrency control, and integrate with payment gateways securely. The platform should maintain a P99 latency under 200ms for seat selection and booking confirmation.

Constraints
  • Seat locking must prevent double booking with a lock timeout of 5 minutes
  • System must handle 10,000 concurrent seat lock requests per second during peak
  • Payment integration must be secure with PCI DSS compliance and support retries
  • P99 latency for seat selection and booking confirmation must be under 200ms
  • Data consistency for seat availability must be maintained across distributed services
  • User sessions and seat locks must expire automatically to avoid stale locks
📋
Guided Steps
1/5
Step 1
Designing Seat Locking Mechanism
How would you design the seat locking system to prevent double booking under high concurrency?
💡 Hint
Consider distributed locks with TTL and atomic operations to avoid stale locks and race conditions.
Key Decision
Use Redis with Redlock algorithm for distributed seat locking with a 5-minute TTL to ensure atomic lock acquisition and automatic expiration.
Interviewer Expectation
Mid: Names Redis with TTL for locks. Senior: Explains Redlock algorithm for distributed consensus and why simple DB row locks or Memcached fail under network partitions.
⚠️Common Wrong Answer
Using database row-level locks for seat locking - leads to high contention and poor scalability under 10K concurrent requests.
Step 2
Handling Concurrency and Consistency
How do you ensure strong consistency of seat availability across distributed services and prevent race conditions during booking confirmation?
💡 Hint
Think about atomic state transitions and idempotency in distributed transactions.
Key Decision
Use a combination of Redis for seat lock state and Cassandra with lightweight transactions (LWT) for booking confirmation to ensure linearizable writes and prevent double booking.
Interviewer Expectation
Mid: Mentions Cassandra for storage. Senior: Explains why Cassandra LWT is chosen over MySQL transactions due to horizontal scalability and how Redis lock state complements it.
⚠️Common Wrong Answer
Relying solely on eventual consistency databases like DynamoDB without atomic check-and-set leads to double bookings.
Step 3
Integrating Payment Gateway Securely
How would you integrate payment processing ensuring security, retries, and idempotency?
💡 Hint
Consider asynchronous payment callbacks, idempotent APIs, and PCI DSS compliance.
Key Decision
Integrate with Stripe using webhook callbacks for payment status, implement idempotency keys in payment requests, and isolate payment data in a PCI DSS compliant vault.
Interviewer Expectation
Mid: Names Stripe and webhooks. Senior: Details idempotency key usage, retry logic, and separation of payment data to meet PCI compliance.
⚠️Common Wrong Answer
Synchronous payment calls blocking booking confirmation - causes increased latency and poor user experience.
Step 4
Ensuring Low Latency and Scalability
How do you design the system to maintain P99 latency under 200ms during peak loads?
💡 Hint
Think about caching, asynchronous processing, and horizontal scaling of components.
Key Decision
Use Redis caching for seat availability reads, Kafka for asynchronous event processing of bookings, and horizontally scale stateless API servers behind a load balancer.
Interviewer Expectation
Mid: Mentions caching and load balancers. Senior: Explains Kafka event-driven architecture to decouple booking confirmation and payment processing, reducing blocking calls.
⚠️Common Wrong Answer
Direct synchronous DB writes for every seat check - leads to high latency and DB bottlenecks.
Step 5
Designing APIs for Seat Locking and Booking
Sketch 3 core API endpoints for seat locking, booking confirmation, and payment status retrieval.
💡 Hint
Consider request/response payloads, idempotency, and error handling.
Key Decision
POST /lockSeats to acquire seat locks with TTL, POST /confirmBooking to finalize booking and trigger payment, GET /paymentStatus to query payment outcome with idempotency keys.
Interviewer Expectation
Mid: Defines basic endpoints. Senior: Details request validation, idempotency keys, lock expiration handling, and asynchronous payment status updates.
⚠️Common Wrong Answer
No idempotency or lock expiration handling in APIs - leads to inconsistent state and poor UX.
🔌
API Design Challenge
Sketch 3 core REST API endpoints for the ticketing system focusing on seat locking, booking confirmation, and payment status.
Hints
  • How does the client request to lock seats and handle lock expiration?
  • How does the client confirm booking and trigger payment?
  • How does the client query payment status and handle failures?
📊
Scoring Rubric
▼ Show
Must Have - 60%
  • Use Redis with Redlock for distributed seat locking to handle concurrency
  • Use Cassandra LWT for atomic booking confirmation to prevent double booking
  • Integrate payment gateway with idempotent APIs and webhook callbacks
  • Design APIs with seat lock acquisition, booking confirmation, and payment status endpoints
Good to Have - 30%
  • Use Kafka for asynchronous event processing to reduce blocking calls
  • Implement Redis caching for seat availability to meet latency requirements
  • Horizontally scale stateless API servers behind load balancers
Bonus - 10%
  • Explain PCI DSS compliance and data isolation for payment security
  • Design automatic seat lock expiration and cleanup mechanisms
Anti-patterns to Avoid
Using database row-level locks for seat locking - causes contention and poor scalability under high concurrency
Relying solely on eventual consistency databases without atomic check-and-set - leads to double bookings
Synchronous payment calls blocking booking confirmation - increases latency and degrades user experience
No idempotency in payment APIs - causes duplicate charges and inconsistent state
Direct synchronous DB reads/writes for every seat check without caching - causes high latency and DB overload
Ignoring seat lock expiration - leads to stale locks and reduced seat availability
✅
Model Answer
▼ Reveal

The system uses Redis with Redlock algorithm for distributed seat locking with a 5-minute TTL to prevent stale locks and race conditions. Cassandra with lightweight transactions (LWT) is used for atomic booking confirmation to ensure strong consistency and horizontal scalability. Payment integration is done via Stripe with webhook callbacks and idempotency keys to ensure secure and reliable payment processing. Kafka is employed for asynchronous event-driven processing to decouple booking confirmation and payment, reducing latency. Redis caching is used for seat availability reads to meet P99 latency under 200ms during peak loads. Stateless API servers are horizontally scaled behind load balancers for fault tolerance and scalability. Automatic seat lock expiration after 5 minutes releases stale locks and improves seat availability. APIs are designed with idempotency keys and clear error handling to ensure reliable client-server interactions.

Key Decisions
  • Use Redis Redlock with 5-minute TTL to ensure atomic seat lock acquisition and automatic expiration
  • Use Cassandra LWT for booking confirmation to guarantee linearizable writes and prevent double booking
  • Integrate Stripe payment gateway with webhook callbacks and idempotency keys to handle retries and ensure PCI DSS compliance
  • Employ Kafka for asynchronous event-driven architecture to decouple booking confirmation and payment processing, reducing blocking calls
  • Implement Redis caching for seat availability to meet strict latency requirements
  • Horizontally scale stateless API servers behind load balancers for fault tolerance and scalability
  • Design APIs with idempotency keys and handle lock expiration to maintain consistent state and good user experience
  • Redis with Redlock algorithm for distributed seat locking with TTL to prevent stale locks and race conditions
  • Cassandra with lightweight transactions (LWT) for atomic booking confirmation ensuring strong consistency and horizontal scalability
  • Stripe payment gateway integration with webhook callbacks and idempotency keys for secure, reliable payment processing
  • Kafka for asynchronous event-driven processing decoupling booking confirmation and payment to reduce latency
  • Redis caching layer for seat availability reads to meet P99 latency under 200ms during peak loads
  • Stateless API servers horizontally scaled behind load balancers for fault tolerance and scalability
  • Automatic seat lock expiration after 5 minutes to release stale locks and improve seat availability
  • API design with idempotency keys and clear error handling to ensure reliable client-server interactions

Practice

(1/5)
1. In the job application tracking flow, at step 5 the Application Processor updates the candidate's application status in the database. What happens if the database write at this step fails due to a transient network error?
easy
A. The Application Processor retries the write immediately, blocking the workflow until success
B. The Application Processor logs the failure and queues the update for asynchronous retry later
C. The Application Processor skips the update and marks the application as failed permanently
D. The Application Processor rolls back the entire application submission transaction

Solution

  1. Step 1: Understand failure handling at Application Processor

    Transient DB errors should not block user workflow or cause permanent failure.

  2. Step 2: Evaluate options

    Immediate retry blocking (A) hurts latency; skipping update (C) loses data; rolling back entire submission (D) is heavy-handed. Queuing for async retry (B) ensures eventual consistency without blocking.

  3. Final Answer:

    Option B -> Option B

  4. Quick Check:

    Async retry decouples transient failures from user flow [check]
Hint: Async retry avoids blocking on transient DB errors [check]
Common Mistakes:
2. If the Bloom filter's hash functions are not independent and produce correlated outputs, what is the exact failure mode observed?
medium
A. The bit array will saturate quickly causing excessive false positives and reduced filter effectiveness
B. The filter will have false negatives, incorrectly rejecting existing members
C. The false positive rate increases beyond the expected theoretical rate
D. Insertions will fail silently without updating the bit array

Solution

  1. Step 1: Understand hash function independence role

    Independent hash functions distribute bits uniformly; correlated hashes cause clustering.

  2. Step 2: Trace effect of correlated hashes

    Correlated hashes set overlapping bits, saturating the bit array faster, increasing false positives and reducing filter effectiveness.

  3. Final Answer:

    Option A -> Option A

  4. Quick Check:

    Correlated hashes cause bit array saturation, raising false positives [check]
Hint: Correlated hashes cause bit array saturation and false positives [check]
Common Mistakes:
3. If the Kafka cluster used for buffering document update events becomes unavailable, what is the immediate failure mode in the full-text search indexing pipeline?
medium
A. The system automatically switches to a backup message queue with identical ordering guarantees
B. Document update ingestion blocks, causing the entire indexing pipeline to stall and new updates to be lost if not retried
C. The indexing workers continue processing stale events from local cache, causing outdated search results
D. The inverted index becomes corrupted due to missing update events

Solution

  1. Step 1: Understand Kafka unavailability impact

    Without Kafka, ingestion of new document updates cannot proceed, causing blocking or stalling.

  2. Step 2: Evaluate options

    Indexing workers do not have local caches of events (A) and cannot continue processing. Automatic failover to a backup queue with identical ordering (C) is a designed mitigation. Index corruption (D) does not happen immediately; missing events cause stale results but not corruption.

  3. Final Answer:

    Option A -> Option A

  4. Quick Check:

    Failover to backup queue prevents pipeline stall [check]
Hint: Kafka outage stalls ingestion unless backup queue with ordering [check]
Common Mistakes:
4. Without the Kafka message queue, what exactly breaks in the chat delivery flow?
medium
A. Alice's send blocks until Bob responds; if Bob's server crashes, message is lost with no retry
B. Messages are encrypted incorrectly causing security breaches
C. Messages are duplicated multiple times due to lack of deduplication
D. The UI shows messages as delivered even if Bob never received them

Solution

  1. Step 1: Trace message flow without Kafka

    Without Kafka, Chat Server A must synchronously contact Bob's server. If Bob's server is slow, Alice's send blocks; if Bob's server crashes, no retry or persistence exists.

  2. Step 2: Eliminate unrelated failure modes

    Encryption issues (A) unrelated to Kafka. Duplication (C) and UI false delivery (D) are mitigated by Kafka's ordering and delivery semantics but not the primary failure here.

  3. Final Answer:

    Option A -> Option A

  4. Quick Check:

    No Kafka -> synchronous send blocks and message loss on Bob crash [check]
Hint: No Kafka -> synchronous send blocks and message lost if recipient crashes [check]
Common Mistakes:
5. At 10x transaction volume, which component of a relational database system is most likely to become the bottleneck first, and why?
hard
A. The storage engine, because disk I/O bandwidth saturates quickly
B. The query optimizer, because it cannot generate execution plans fast enough
C. The lock manager, due to increased contention causing transaction delays
D. The network layer, as increased client connections overwhelm bandwidth

Solution

  1. Step 1: Identify bottleneck under high concurrency

    Lock manager handles concurrency control; at 10x load, lock contention increases exponentially.

  2. Step 2: Compare other components

    Query optimizer scales well with caching; storage and network scale with hardware upgrades; lock manager contention is harder to mitigate.

  3. Final Answer:

    Option C -> Option C

  4. Quick Check:

    Lock manager contention -> first bottleneck at high transaction scale [check]
Hint: Lock manager contention grows fastest at scale [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