Bird
Raised Fist0

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

HLDhardInterview freq: high
Choose your preparation mode4 modes available
▶
Request Trace
Step 1/5
API Gateway

Receives seat selection request

User selects seats and sends request to lock seats

Protocol:HTTP REST
BeforeUser has selected seats on client UI but no lock exists
AfterAPI Gateway forwards seat lock request to Seat Lock Service
Seat Lock Service

Attempts to lock requested seats

Checks seat availability and locks seats if free

Protocol:RPC
BeforeSeats are available and unlocked in Cassandra Cluster
AfterSeats are locked for user with a timeout in Cassandra Cluster
Booking Service

Receives lock confirmation and prepares booking

Creates provisional booking record with locked seats

Protocol:RPC
BeforeSeats locked but booking not yet created in Cassandra Cluster
AfterProvisional booking stored in Cassandra Cluster with locked seats
Payment Service

Processes payment request

Sends payment details to external Payment Gateway

Protocol:HTTPS
BeforeBooking provisional, payment not initiated
AfterPayment Gateway authorizes payment, response received
Booking Service

Finalizes booking after payment success

Marks booking as confirmed and releases seat lock

Protocol:RPC
BeforePayment successful, provisional booking exists in Cassandra Cluster
AfterBooking confirmed in Cassandra Cluster, seat lock removed
🏗️
Architecture Diagram
Architecture Diagram
┌───────────────┐
│  API Gateway  │
└───────┬───────┘
        │ HTTP REST
        ▼
┌───────────────────┐
│ Seat Lock Service │
└─────────┬─────────┘
          │ RPC
          ▼
┌───────────────────┐
│ Booking Service   │
└─────────┬─────────┘
          │ RPC
          ▼
┌───────────────────┐
│ Payment Service   │
└─────────┬─────────┘
          │ HTTPS
          ▼
┌───────────────────┐
│ Payment Gateway   │
└─────────┬─────────┘
          │
          ▼
┌───────────────────┐
│ Cassandra Cluster │
└───────────────────┘

This architecture illustrates a vertical request flow for a ticketing system like BookMyShow. The API Gateway receives the user's seat selection and forwards it to the Seat Lock Service, which locks seats in Cassandra to prevent double booking. The Booking Service creates a provisional booking record referencing the locked seats. Payment Service then processes payment via the external Payment Gateway. Upon successful payment, the Booking Service finalizes the booking and releases the seat lock. This design ensures concurrency control by locking seats early and uses a durable Cassandra store for state. The separation of concerns between locking, booking, and payment services allows scalability and fault isolation.

Primary Focus

✓

Practice

(1/5)
1. In a composite index on columns (A, B), a query filters only on column B. At step 3 in the query execution plan, the database engine uses the composite index. What is the state of index usage at this step?
easy
A. The composite index cannot be used efficiently because column A is not filtered, causing a full index scan
B. The composite index is fully used to seek on column B alone efficiently
C. The database ignores the composite index and uses a table scan instead
D. The composite index is partially used by scanning leaf nodes but with poor performance

Solution

  1. Step 1: Understand composite index column order

    Composite indexes are ordered by the first column (A), then second (B). Queries filtering only on B cannot efficiently seek the index without filtering on A.
  2. Step 2: Analyze index usage at step 3

    Since column A is not filtered, the engine must scan the entire index or large portions, resulting in a full index scan rather than an efficient seek.
  3. Final Answer:

    Option A -> Option A
  4. Quick Check:

    Composite index requires leading column filter for efficient seeks [check]
Hint: Composite index needs leading column filter for seeks [check]
Common Mistakes:
2. In a fraud detection system ingesting thousands of transactions per second, which component is best suited to decouple the high-throughput transaction ingestion from downstream real-time scoring to avoid backpressure?
easy
A. Use a relational database with batch inserts to buffer transactions
B. Use direct synchronous HTTP calls from ingestion to scoring service
C. Use an in-memory cache like Redis to store incoming transactions temporarily
D. Use a distributed message queue like Kafka with partitioning by user ID

Solution

  1. Step 1: Identify decoupling mechanism

    Relational DB batch inserts (A) add latency and don't handle high write throughput well. Redis (C) lacks durability guarantees for buffering. Direct synchronous calls (D) cause backpressure and tight coupling.
  2. Step 2: Evaluate Kafka suitability

    Kafka supports high-throughput, partitioned by user ID to maintain ordering per user, and durable storage, enabling asynchronous processing and backpressure handling.
  3. Final Answer:

    Option D -> Option D
  4. Quick Check:

    Kafka partitions decouple ingestion and scoring with durability and ordering [check]
Hint: Kafka partitions buffer high-throughput streams reliably [check]
Common Mistakes:
3. A web application needs to route incoming HTTP requests to multiple backend services based on URL paths, while also performing authentication and rate limiting. Which component is best suited to handle this?
easy
A. Reverse Proxy that only forwards requests to backend servers without modifying requests
B. Load Balancer that distributes traffic evenly across servers without inspecting HTTP headers
C. API Gateway that routes requests, enforces authentication, and applies rate limiting policies
D. DNS-based load balancing that resolves domain names to multiple IP addresses randomly

Solution

  1. Step 1: Identify component roles

    Load Balancers distribute traffic but do not inspect or modify requests; Reverse Proxies forward requests but lack built-in authentication and rate limiting; DNS-based load balancing is coarse and lacks request-level control.
  2. Step 2: Match scenario requirements

    API Gateway supports routing based on URL paths, authentication, and rate limiting, fulfilling all requirements.
  3. Final Answer:

    Option C -> Option C
  4. Quick Check:

    API Gateway handles routing and policies at HTTP layer [check]
Hint: API Gateway = routing + auth + rate limiting [check]
Common Mistakes:
4. For a distributed file system requiring strong consistency on metadata updates but high availability, which architecture is most appropriate?
medium
A. Use a consensus-based Metadata Server cluster (e.g., Paxos or Raft) to coordinate updates
B. Use a single Metadata Server with synchronous replication to backups
C. Use multiple independent Metadata Servers sharding namespace without coordination
D. Use eventual consistency with asynchronous metadata replication across servers

Solution

  1. Step 1: Analyze consistency and availability needs

    Strong consistency requires coordination; high availability requires fault tolerance.
  2. Step 2: Evaluate architectures

    Consensus-based clusters provide strong consistency and tolerate failures; single server risks downtime; independent shards lack coordination; eventual consistency violates strong consistency.
  3. Final Answer:

    Option A -> Option A
  4. Quick Check:

    Consensus clusters balance strong consistency and availability [check]
Hint: Consensus clusters ensure strong consistency with availability [check]
Common Mistakes:
5. You need to model a social media feed with millions of users and high write throughput. Which data modeling approach is best to optimize for write scalability and read performance?
medium
A. Embed all posts and comments inside each user document to minimize joins.
B. Use a graph database to model user relationships and posts for efficient traversal.
C. Store all posts in a single collection with a compound index on user and timestamp for fast queries.
D. Use a referencing pattern with separate collections for users, posts, and comments, and denormalize popular posts into user feed documents.

Solution

  1. Step 1: Analyze write scalability and read patterns

    High write throughput and millions of users require scalable writes and efficient feed reads.
  2. Step 2: Evaluate referencing with denormalization

    Referencing separates concerns; denormalizing popular posts into feeds optimizes read performance without large documents.
  3. Final Answer:

    Option D -> Option D
  4. Quick Check:

    Referencing plus denormalization balances write scale and read speed [check]
Hint: Reference plus denormalize popular data for scalable writes and fast reads [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