Bird
Raised Fist0

Design a Hotel Booking System - Inventory, Reservation, Double Booking Prevention

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

Receives search request

User requests available rooms for given dates

Protocol:HTTP/REST
BeforeUser has input search criteria on client
AfterAPI Gateway forwards search request to Search Service
Search Service

Queries Inventory DB

Fetches available rooms matching criteria

Protocol:SQL Query
BeforeSearch Service has search parameters
AfterSearch Service receives room availability data
API Gateway

Returns search results

Sends available rooms list back to user

Protocol:JSON Response
BeforeSearch Service has availability data
AfterUser sees available rooms on client UI
Booking Srv

Requests distributed lock

Attempts to acquire lock for requested room and dates

Protocol:Redis RedLock
BeforeBooking Srv received booking request from API Gateway
AfterBooking Srv holds lock preventing concurrent bookings
Booking Srv

Writes reservation

Creates reservation record in Reservation DB

Protocol:SQL Insert
BeforeBooking Srv holds distributed lock
AfterReservation DB contains new booking record
Distributed Locking (Redis RedLock)

Releases lock

Frees lock after reservation is saved

Protocol:Redis Command
BeforeLock held by Booking Srv
AfterLock released for other booking attempts
API Gateway

Returns booking confirmation

Sends confirmation response to user

Protocol:HTTP/REST
BeforeBooking Srv completed reservation
AfterUser receives booking confirmation
🏗️
Architecture Diagram
Architecture Diagram
┌───────────────┐
│  API Gateway  │
└───────┬───────┘
        │ HTTP/REST
        ▼
┌───────────────┐
│ Search Service│
└───────┬───────┘
        │ SQL Query
        ▼
┌───────────────┐
│ Inventory DB  │
└───────┬───────┘
        │ JSON Response
        ▲
        │
┌───────┴───────┐
│ Booking Srv   │
└───────┬───────┘
        │ Redis RedLock
        ▼
┌───────────────┐
│ Distributed   │
│ Locking (Redis│
│ RedLock)      │
└───────┬───────┘
        │ Lock Acquired
        ▼
┌───────────────┐
│ Reservation DB│
└───────────────┘

This Hotel Booking System architecture uses an API Gateway as the single entry point for client requests. The Search Service queries the Inventory DB to provide available rooms. When a user attempts to book a room, the Booking Service first acquires a distributed lock via Redis RedLock to prevent double booking of the same room for overlapping dates. Once the lock is acquired, the Booking Service writes the reservation to the Reservation DB and then releases the lock. This locking mechanism ensures strong consistency and prevents race conditions in concurrent booking attempts. The system cleanly separates read (search) and write (booking) paths, optimizing for availability and correctness.

Primary Focus

✓

Practice

(1/5)
1. In a distributed counter system using sharded CRDTs, at Step 4 the Aggregator node merges shard states received from replicas. What is the Aggregator's state immediately after merging two shards with counts 100 and 150?
easy
A. The Aggregator state is the average of the two counts: 125, to smooth spikes
B. The Aggregator state is the maximum of the two counts: 150, to avoid double counting
C. The Aggregator state is the sum: 250, reflecting all increments
D. The Aggregator state resets to zero after merging to avoid stale data

Solution

  1. Step 1: Understand CRDT merge semantics for counters

    Sharded counters merge by summing counts from each shard to reflect total increments without double counting.
  2. Step 2: Apply merge to counts 100 and 150

    Sum is 250, representing combined increments from both shards.
  3. Final Answer:

    Option C -> Option C
  4. Quick Check:

    CRDT counters merge by summing shard values [check]
Hint: CRDT counters merge by summing shard counts [check]
Common Mistakes:
2. A web crawler must efficiently avoid re-crawling the same URLs too frequently while ensuring freshness. Which component best handles URL scheduling and politeness constraints?
easy
A. Implement a URL Frontier with priority queues and politeness policies
B. Use a distributed key-value store to store page content for freshness checks
C. Rely on the PageRank component to prioritize URLs for crawling
D. Use a message queue to distribute URLs randomly among crawler workers

Solution

  1. Step 1: Identify URL scheduling role

    The URL Frontier manages which URLs to crawl next, enforcing politeness and freshness constraints.
  2. Step 2: Evaluate other components

    PageRank ranks pages post-crawl, not for scheduling. Distributed KV stores hold content but don't schedule. Random distribution ignores politeness.
  3. Final Answer:

    Option A -> Option A
  4. Quick Check:

    URL Frontier enforces crawl politeness and freshness [check]
Hint: URL Frontier schedules URLs with politeness [check]
Common Mistakes:
3. A load balancer must detect unhealthy backend servers and reroute traffic without client impact. Which component is primarily responsible for detecting server health status?
easy
A. Health check module that periodically probes backend servers
B. Client-side retry logic to avoid failed servers
C. Load balancer's session persistence cache to track server availability
D. DNS resolver that removes unhealthy servers from DNS responses

Solution

  1. Step 1: Identify health detection responsibility

    The health check module actively probes backend servers to determine their health status.
  2. Step 2: Eliminate other options

    DNS resolver changes are slow and indirect; session persistence caches track sessions, not health; client-side retries do not detect server health.
  3. Final Answer:

    Option A -> Option A
  4. Quick Check:

    Health check module probes servers directly for health [check]
Hint: Health checks probe servers directly to detect failures [check]
Common Mistakes:
4. Without the Global Traffic Manager component in a multi-CDN setup, what is the most likely failure scenario when one CDN provider becomes unavailable?
medium
A. Origin server detects CDN failure and redirects traffic to healthy CDNs
B. Clients continue sending requests to the failed CDN, causing increased latency and errors
C. User requests automatically failover to the next CDN without delay
D. Edge caches replicate content from other CDNs to cover the outage

Solution

  1. Step 1: Understand role of Global Traffic Manager in failover

    It dynamically routes traffic away from failed CDNs. Without it, failover must be handled elsewhere.
  2. Step 2: Trace failure without Global Traffic Manager

    Origin server may attempt to redirect traffic, but this adds latency and is less dynamic than traffic manager.
  3. Step 3: Eliminate other options

    Automatic client failover (A) requires client intelligence not assumed here. Clients sending to failed CDN (B) is possible but less likely if origin redirects. Edge caches (D) do not replicate across CDNs automatically.
  4. Final Answer:

    Option A -> Option A
  5. Quick Check:

    Without traffic manager, origin server redirects traffic causing latency and partial failover [check]
Hint: No traffic manager -> origin server handles failover with latency penalty [OK]
Common Mistakes:
5. At 10x scale, which component in the CI/CD pipeline is most likely to become the bottleneck first, and why?
hard
A. Artifact Registry, because storage and retrieval latency increase with artifact volume
B. Test Runner, because parallel test execution saturates CPU and memory resources
C. Deployment Orchestrator, because coordinating thousands of concurrent deployments causes state management overhead
D. Rollback Manager, because tracking and reverting large numbers of deployments requires heavy database writes

Solution

  1. Step 1: Analyze artifact registry scaling challenges

    At 10x scale, artifact volume grows massively, increasing storage needs and retrieval latency, stressing the registry's throughput and storage backend.
  2. Step 2: Compare other components

    Test runner scales with parallelism; orchestrator is stateless or sharded; rollback manager writes are less frequent and can be batched.
  3. Final Answer:

    Option A -> Option A
  4. Quick Check:

    Artifact registry storage and latency bottleneck at scale [check]
Hint: Artifact registry storage grows fastest, bottleneck first [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