Practice/Amazon/Design a Hotel Booking System

Design a Hotel Booking System

System DesignMust

Problem Statement

Design a hotel booking system like Booking.com or Expedia where users search for hotels by location and dates, see room types and prices, and make reservations. The system must track nightly inventory, apply complex pricing rules, and ensure two people are not sold the last room at the same time.

Interviewers ask this to test whether you can model real-world constraints in a relational schema, write correct availability queries, and handle high-contention reservations with strong transactional semantics. They also want to see how you separate search from booking, design for scale, and manage multi-step workflows like holds, payments, confirmations, and cancellations.

Key Requirements

Functional

• Hotel search -- users search for hotels by location, dates, number of guests, and filters (price range, amenities, star rating)
• Pricing display -- users view room types with accurate nightly prices, fees/taxes, and total cost for a stay
• Reservation -- users book a room for specific dates with payment and receive a confirmation number
• Booking management -- users view, modify (when allowed), and cancel their reservations with appropriate refund policies

Non-Functional

• Scalability -- support millions of searches per day with hundreds of thousands of properties, handling seasonal demand spikes
• Reliability -- maintain 99.9% uptime for booking operations; zero double-bookings for the same room and dates
• Latency -- search results returned under 500ms, booking confirmation under 2 seconds including payment processing
• Consistency -- strong consistency for inventory and booking operations; eventual consistency for search results and pricing display

What Interviewers Focus On

Based on real interview experiences, these are the areas interviewers probe most deeply:

1. Inventory Model and Double-Booking Prevention

Room inventory is scarce and highly contended during peak times. The data model must track availability at per-night granularity to handle overlapping multi-night stays correctly.

Hints to consider:

• Model inventory as per-room-type, per-night availability counters rather than hotel-level aggregates, since multi-night stays span different availability windows
• Use row-level locking or atomic decrements on availability records during reservation to prevent race conditions
• Implement short-lived inventory holds (5-10 minutes) when users begin checkout, releasing via TTL if they abandon the flow
• Consider optimistic concurrency with version checks: read availability, present to user, then conditionally decrement only if the version has not changed

2. Search vs Booking Path Separation

Search traffic dwarfs booking volume and has very different access patterns. Coupling search to the transactional database creates performance problems.

Hints to consider:

• Use Elasticsearch or a similar search engine for hotel discovery with filters on location, price, amenities, and availability signals
• Maintain a separate availability index that is eventually consistent, updated by change data capture from the booking database
• Validate actual availability against the source-of-truth database at booking time, gracefully handling the case where a room sold out between search and checkout
• Cache minimum price per hotel per date range for search result display, refreshing on a schedule or via events

3. Multi-Step Booking Workflow

The booking flow spans inventory hold, payment authorization, booking confirmation, and notification, with each step potentially failing.

Hints to consider:

• Design the checkout as a saga: place inventory hold, authorize payment, confirm booking, send notification, with compensating actions at each step
• Use idempotency keys on payment calls so retries from network timeouts do not result in double charges
• Implement a timeout mechanism where incomplete bookings are automatically canceled and inventory is released
• Handle payment failures by releasing the inventory hold and returning the user to the search results with a clear error message

4. Dynamic Pricing and Rate Management

Hotel pricing varies by date, room type, occupancy, length of stay, and demand, requiring a flexible pricing engine.

Hints to consider:

• Store base rates per room type per date, with pricing rules applied as overlays (weekend surcharge, seasonal multiplier, length-of-stay discount)
• Compute total stay cost at booking time by aggregating nightly rates, applying applicable rules, and adding taxes and fees
• Cache computed prices for common queries (standard room, 2 nights) with short TTLs, recalculating on booking confirmation
• Design the pricing engine as a separate service that can be updated independently without affecting search or booking

Suggested Approach

Step 1: Clarify Requirements

Confirm scope with the interviewer. Ask about the number of properties and rooms, geographic distribution, whether the system is a direct hotel platform or an aggregator, and if group bookings or conference blocks are in scope. Clarify cancellation and modification policies: are they hotel-specific or platform-wide? Establish whether loyalty programs, promotional codes, or dynamic pricing algorithms are in scope.