Design a Hotel Booking System

Problem Statement

Build a hotel booking platform that lets travelers search for accommodations, reserve rooms, and manage their stays. The system must track real-time inventory across thousands of properties, apply dynamic nightly pricing that varies by date and demand, and handle concurrent booking attempts during peak travel periods without overselling. Users search by destination and dates, browse room options with accurate pricing, complete reservations with payment, and manage their bookings through modifications or cancellations.

The central technical challenge is maintaining data integrity when inventory is scarce. When the last available room receives simultaneous booking requests, the system must guarantee that exactly one succeeds. You need to model nightly room availability at scale, compute total stay costs from per-night rates plus taxes and fees, and orchestrate multi-step booking workflows that span payment processing, inventory updates, and confirmation delivery. Your design should separate read-heavy search workloads from write-heavy reservation transactions so each can scale independently.

Key Requirements

Functional

• Hotel search -- Users filter properties by location, check-in and check-out dates, guest count, and amenities, receiving results sorted by relevance or price
• Pricing display -- Show accurate per-night rates, total cost breakdown including taxes and fees, and cancellation policy details before booking
• Room reservation -- Process bookings with payment authorization, atomically update inventory, generate confirmation codes, and send email confirmations
• Booking management -- Allow users to view reservation history, modify dates when policy permits, and cancel with appropriate refund handling

Non-Functional

• Scalability -- Support 10,000 searches per second and 500 bookings per second during peak travel seasons with millions of hotel listings globally
• Reliability -- Guarantee no double-bookings under concurrent load; maintain 99.9 percent uptime for booking transactions with graceful degradation for search during partial outages
• Latency -- Return search results within 300 ms at p95; complete booking confirmation within 2 seconds including payment processing
• Consistency -- Strong consistency for inventory updates during booking; eventual consistency acceptable for search index updates and pricing changes

What Interviewers Focus On

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

1. Inventory Data Modeling with Per-Night Granularity

The heart of the design is how you track room availability. Interviewers want to see per-night, per-room-type modeling rather than a simple boolean at the hotel level, because multi-night stays can span dates with partial availability.

Hints to consider:

• Maintain an inventory table with rows for each combination of hotel, room type, and date, storing an available_count integer
• Partition the table by date range to keep active queries fast while archiving historical data
• Separate static room definitions (capacity, amenities, photos) from time-varying inventory to avoid data duplication
• Index on hotel_id, room_type_id, and date for efficient range scans when checking multi-night availability

2. Concurrency Control to Prevent Double-Booking

When multiple users attempt to book the last room simultaneously, your system must prevent overselling while maintaining throughput. Interviewers expect a discussion of locking strategies and transactional semantics.

Hints to consider:

• Use pessimistic row-level locking (SELECT FOR UPDATE) when decrementing inventory during the booking transaction
• As an alternative, implement optimistic locking with version numbers and retry on version mismatch to reduce lock contention
• Consider a two-phase approach: place a soft hold with a short TTL (five minutes) while the user completes payment, then convert to a confirmed reservation
• Cache "sold out" signals in Redis to short-circuit availability checks for popular date ranges, invalidating on cancellations

3. Separating Search from Booking for Read Scalability

Search traffic vastly exceeds booking volume. Interviewers look for a clear separation between the transactional database and the search infrastructure.

Hints to consider:

• Use Elasticsearch for full-text search on hotel names and descriptions, geospatial queries by location, and faceted filtering by amenities
• Precompute and denormalize availability flags in the search index, refreshing asynchronously from booking events
• Cache popular search queries and minimum hotel prices in Redis with appropriate TTLs
• Fetch detailed per-night availability only for hotels displayed on the current page, not the entire result set

4. Dynamic Pricing Calculation

Hotels apply complex pricing rules including seasonal rates, occupancy surcharges, jurisdiction-specific taxes, and promotional discounts. Interviewers want to see structured thinking about where this logic lives.

Hints to consider:

• Store base nightly rates in a pricing table keyed by hotel, room type, and date range to support seasonal and event-based pricing
• Apply occupancy modifiers and tax rates at query time or within a dedicated pricing service layer
• Cache computed prices for common search patterns to avoid recalculating on every request
• Encapsulate pricing rules in a standalone service that can be updated independently from booking logic

5. Multi-Step Booking Workflow

A reservation spans multiple steps: inventory hold, payment authorization, confirmation creation, and potentially rollback on payment failure. Interviewers probe how you maintain consistency across these steps.

Hints to consider:

• Model bookings with a state machine (PENDING, PAYMENT_AUTHORIZED, CONFIRMED, CANCELLED) and attach idempotency keys for safe retries
• Coordinate steps using a workflow orchestrator or Saga pattern: hold inventory, call payment gateway, finalize reservation, send confirmation
• Implement compensating transactions so that if payment succeeds but confirmation fails, the system retries asynchronously rather than blocking the user
• Run a background job that releases expired holds back to inventory when checkout is abandoned

Suggested Approach

Step 1: Clarify Requirements

Confirm whether the system covers a single hotel chain or a marketplace aggregating thousands of properties. Ask if real-time pricing updates from hotels are required or if overnight batch updates suffice. Verify expected search and booking volumes, geographic distribution, and whether you are integrating with legacy property management systems. Clarify functional boundaries: are you responsible for payment processing or calling an external gateway? Do cancellations refund automatically or require approval?

Step 2: High-Level Architecture

Sketch a service-oriented architecture. A Search Service backed by Elasticsearch handles queries with filters, returning hotel metadata and availability flags. A Booking Service owns the transactional workflow, interacting with PostgreSQL to check precise inventory and create reservations. A Pricing Service computes total costs from base rates, taxes, and fees. A Payment Service wraps interactions with payment gateways. An Inventory Service updates nightly availability counts and publishes events to refresh the search index asynchronously. Place Redis in front of hot paths for caching search results and holding soft-locks during checkout. Use Kafka to decouple inventory updates from search reindexing.

Step 3: Deep Dive on Inventory and Booking Flow

Walk through the core booking transaction. When a user selects dates and a room type, the Booking Service starts a database transaction. It queries the inventory table for all dates in the range using SELECT FOR UPDATE. If every night has at least one available room, it decrements available_count for each date, inserts a reservation row with a generated confirmation code and PENDING status. The service then calls the Payment Service with an idempotency key. On payment success, it updates the reservation to CONFIRMED and commits. On payment failure or timeout, it rolls back, returning inventory to the pool. Explain how row-level locks prevent concurrent transactions from seeing stale availability, and how composite indexing ensures the range scan completes in milliseconds.

Step 4: Address Secondary Concerns

For scalability, partition the inventory table by date and use read replicas for search queries that tolerate slight lag. For reliability, implement idempotency tokens so retries never double-book or double-charge, and use circuit breakers around payment gateway calls. For latency, cache popular searches in Redis with short TTLs and precompute minimum prices per hotel. For consistency, publish inventory changes to Kafka and have a consumer update Elasticsearch, accepting eventual consistency in search while guaranteeing strong consistency on the booking path. Discuss observability: track booking success rates, lock wait times, cache hit rates, and search latency percentiles. Briefly touch on disaster recovery with cross-AZ database replication and Kafka topic mirroring.