Design a Large-Scale Hotel Booking System
Design the backend for a large-scale hotel booking system that supports a very high-traffic consumer application. This application is similar to TikTok, where a hotel can go viral, leading to millions of users simultaneously interacting with the same property.
Users of the system should be able to:
- Browse hotels for a specific city and date range.
- View near real-time availability and prices for any given hotel.
- Place a booking request and receive either a confirmation or a rejection.
The interviewer emphasizes reasoning carefully about business properties first, then deriving the architecture and key trade-offs.
Functional Requirements
- Search for hotels by city, date range, and basic filters.
- For a given hotel and date range, display up-to-date availability (number of rooms left) and price.
- Create a booking for a chosen hotel, room type, and date range.
- Guarantee that the same room-night is not double-booked.
- Optionally support cancellation (can be kept high-level).
Non-Functional Requirements
- High Concurrency:
- The system must handle up to ~100,000 read requests per second (for availability checks) and ~10,000 booking attempts per second at peak.
- Low Latency:
- P99 latency for availability checks and booking confirmation should be less than 200 milliseconds end-to-end from the client's perspective.
- High Availability:
- The system must remain operational even if individual nodes or an entire availability zone fails.
- Consistency Characteristics:
- Weak/eventual consistency is acceptable for displaying availability counts on the UI. Users may occasionally see slightly outdated counts.
- Strong correctness is required for final booking confirmation to prevent double-bookings.
- Message Loss Tolerance:
- For streaming or push-style availability updates to clients, it is acceptable if some update messages are lost, as they will be refreshed soon.
- It is not acceptable to lose actual booking requests or confirmations.
- Hotspot Handling:
- The system must gracefully handle scenarios where certain hotels become extremely popular (e.g., after a viral video), leading to a highly skewed load.
- The design should prevent concentrating all traffic for a single hot hotel onto a single node.
- Latency vs. Reliability Trade-off:
- The discussion should include protocol choices (e.g., HTTP vs. WebSocket vs. UDP or similar) and their impact on latency and reliability.
Specific Discussion Points
The interviewer is particularly interested in the following areas:
- Latency vs. Reliability: When and why might you choose a low-overhead protocol (such as UDP or WebSocket-style persistent connections) over plain HTTP for specific flows? Which parts of the system can tolerate message loss, and which cannot?
- Preventing Double Bookings: Under high concurrency, how do you ensure two users cannot successfully book the last available room-night? Discuss techniques such as rate limiting, request coalescing/merging, throttling, and concurrency control (e.g., locks, atomic counters, queues).
- Sharding / Horizontal Scaling for Hot Hotels: How would you horizontally partition the load for a very hot hotel? Compare strategies like sharding by room (e.g., room ID or room type) versus bucketizing by user (e.g., hashing on user ID) and discuss their pros and cons.
Assume you have the flexibility to choose any technologies (e.g., relational vs. NoSQL databases, caches like Redis, message queues like Kafka, etc.).
Task
Design the system at a high level, covering the following aspects:
- Identify the major components and services.
- Propose a data model for hotels, rooms, inventory, and bookings.
- Describe the end-to-end flows for availability lookup and booking confirmation.
- Explain how your design achieves:
- Low latency with acceptable reliability trade-offs.
- Prevention of double-bookings despite high concurrency.
- Effective handling of hot hotels through sharding/partitioning.
- Explicitly call out the key trade-offs made and the rationale behind those choices.
AI interview prep
Core dilemma
Balancing extreme read scalability and low latency for availability (eventually consistent) with strict write consistency and no double-booking guarantees for bookings (strongly consistent), all under high concurrency and severe hotspot conditions.
3 tradeoffs and 3 stress tests locked
Interview prep
Unlock the interviewer X-Ray rubric, tradeoff matrix, stress tests, clarifying questions, and key concepts.
Design a Large-Scale Hotel Booking System
Design the backend for a large-scale hotel booking system that supports a very high-traffic consumer application. This application is similar to TikTok, where a hotel can go viral, leading to millions of users simultaneously interacting with the same property.
Users of the system should be able to:
- Browse hotels for a specific city and date range.
- View near real-time availability and prices for any given hotel.
- Place a booking request and receive either a confirmation or a rejection.
The interviewer emphasizes reasoning carefully about business properties first, then deriving the architecture and key trade-offs.
Functional Requirements
- Search for hotels by city, date range, and basic filters.
- For a given hotel and date range, display up-to-date availability (number of rooms left) and price.
- Create a booking for a chosen hotel, room type, and date range.
- Guarantee that the same room-night is not double-booked.
- Optionally support cancellation (can be kept high-level).
Non-Functional Requirements
- High Concurrency:
- The system must handle up to ~100,000 read requests per second (for availability checks) and ~10,000 booking attempts per second at peak.
- Low Latency:
- P99 latency for availability checks and booking confirmation should be less than 200 milliseconds end-to-end from the client's perspective.
- High Availability:
- The system must remain operational even if individual nodes or an entire availability zone fails.
- Consistency Characteristics:
- Weak/eventual consistency is acceptable for displaying availability counts on the UI. Users may occasionally see slightly outdated counts.
- Strong correctness is required for final booking confirmation to prevent double-bookings.
- Message Loss Tolerance:
- For streaming or push-style availability updates to clients, it is acceptable if some update messages are lost, as they will be refreshed soon.
- It is not acceptable to lose actual booking requests or confirmations.
- Hotspot Handling:
- The system must gracefully handle scenarios where certain hotels become extremely popular (e.g., after a viral video), leading to a highly skewed load.
- The design should prevent concentrating all traffic for a single hot hotel onto a single node.
- Latency vs. Reliability Trade-off:
- The discussion should include protocol choices (e.g., HTTP vs. WebSocket vs. UDP or similar) and their impact on latency and reliability.
Specific Discussion Points
The interviewer is particularly interested in the following areas:
- Latency vs. Reliability: When and why might you choose a low-overhead protocol (such as UDP or WebSocket-style persistent connections) over plain HTTP for specific flows? Which parts of the system can tolerate message loss, and which cannot?
- Preventing Double Bookings: Under high concurrency, how do you ensure two users cannot successfully book the last available room-night? Discuss techniques such as rate limiting, request coalescing/merging, throttling, and concurrency control (e.g., locks, atomic counters, queues).
- Sharding / Horizontal Scaling for Hot Hotels: How would you horizontally partition the load for a very hot hotel? Compare strategies like sharding by room (e.g., room ID or room type) versus bucketizing by user (e.g., hashing on user ID) and discuss their pros and cons.
Assume you have the flexibility to choose any technologies (e.g., relational vs. NoSQL databases, caches like Redis, message queues like Kafka, etc.).
Task
Design the system at a high level, covering the following aspects:
- Identify the major components and services.
- Propose a data model for hotels, rooms, inventory, and bookings.
- Describe the end-to-end flows for availability lookup and booking confirmation.
- Explain how your design achieves:
- Low latency with acceptable reliability trade-offs.
- Prevention of double-bookings despite high concurrency.
- Effective handling of hot hotels through sharding/partitioning.
- Explicitly call out the key trade-offs made and the rationale behind those choices.