Design a Hotel Booking System

Problem Statement

Build a hotel booking platform that enables travelers to discover accommodations, reserve rooms, and manage their stays. Your system must handle the complexities of real-time inventory tracking across thousands of properties, dynamic pricing that varies by date and demand, and concurrent booking attempts during high-traffic periods like holiday weekends. Users will search by destination and travel dates, browse room options with accurate pricing, complete reservations with payment, and manage their bookings through modifications or cancellations.

The technical challenge lies in maintaining data integrity when inventory is scarce -- preventing double-bookings while serving search results with sub-second latency. You need to model nightly room availability at scale, compute total stay costs from per-night rates and fees, and orchestrate multi-step booking flows that span payment processing, inventory updates, and confirmation delivery. Think through how your design handles race conditions when the last available room receives simultaneous booking attempts, and how you separate read-heavy search workloads from write-heavy reservation transactions.

Key Requirements

Functional

• Hotel search -- Users filter properties by location, check-in/check-out dates, guest count, and amenities (WiFi, parking, pool), 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 across global regions
• Reliability -- Guarantee no double-bookings under concurrent load; ensure 99.9% uptime for booking transactions and graceful degradation for search during partial outages
• Latency -- Return search results within 300ms 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 Management and Data Modeling

The heart of your design is how you track room availability at a granular level. Interviewers want to see you model inventory per night, per room type, rather than treating availability as a simple boolean at the hotel level. A multi-night stay spanning dates with partial availability must be handled correctly.

Hints to consider:

• Maintain an inventory table with rows for each (hotel, room_type, date, available_count) tuple to track nightly availability
• Use database partitioning by date range to keep recent inventory queries fast as historical data accumulates
• Consider separating room definitions (capacity, amenities) from time-based inventory to avoid data duplication
• Index by (hotel_id, room_type_id, date) for efficient range scans when checking multi-night availability

2. Concurrency Control and Race Conditions

When multiple users attempt to book the last available room simultaneously, your system must prevent overselling. Interviewers expect you to discuss transactional semantics, locking strategies, and how to maintain throughput under contention.

Hints to consider:

• Use pessimistic row-level locking (SELECT FOR UPDATE) when decrementing inventory during booking transactions
• Implement optimistic locking with version numbers if your database struggles under lock contention, then retry on version mismatch
• Consider a two-phase approach: soft-hold inventory with a short TTL (5 minutes) while user completes payment, then convert to confirmed reservation
• Cache "sold out" signals in Redis to short-circuit availability checks without hitting the database, invalidating on cancellations

3. Search Performance and Read Scalability

Search traffic vastly exceeds booking volume, and users expect fast results with complex filters. Interviewers look for separation of concerns between your transactional database and search infrastructure.

Hints to consider:

• Use Elasticsearch or similar for full-text search on hotel names/descriptions, geospatial queries, and faceted filtering by amenities
• Precompute and denormalize availability flags (has_availability_for_dates) in your search index, refreshing asynchronously from booking events
• Cache popular search queries and minimum prices per hotel in Redis with appropriate TTLs to reduce load
• Paginate results and fetch detailed availability only for hotels on the current page, not the entire result set

4. Database Write Scaling Under Heavy Publishing

When many reservations arrive simultaneously -- for instance during a flash sale or holiday opening -- write throughput to your inventory tables becomes a bottleneck. Interviewers probe how you handle hot partitions where a popular hotel or date range concentrates writes on the same rows.

Hints to consider:

• Shard inventory writes by hotel region or property group so that hot destinations do not contend with cold ones
• Batch multiple hold requests and process them in micro-batches to reduce round trips and lock duration
• Use write-ahead queues (Kafka or SQS) to absorb booking spikes and drain them at a controlled rate
• Monitor lock wait times and automatically route overflow traffic to retry queues with exponential backoff

5. Multi-Step Booking Workflow and Fault Tolerance

A booking is not atomic -- it involves inventory hold, payment authorization, reservation creation, confirmation delivery, and potentially rollback if payment fails. Interviewers want to see how you maintain consistency across these steps and recover gracefully from partial failures.

Hints to consider:

• Model bookings with a state machine (PENDING, PAYMENT_AUTHORIZED, CONFIRMED, CANCELLED) and idempotency keys for safe retries
• Use a workflow orchestrator or Saga pattern to coordinate steps: hold inventory, call payment gateway, finalize reservation, send email
• Implement compensating transactions: if payment succeeds but confirmation fails, retry asynchronously rather than blocking the user
• Store holds with expiration timestamps; a background job releases expired holds to reclaim inventory for other users

Suggested Approach

Step 1: Clarify Requirements

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

Step 2: High-Level Architecture

Sketch a service-oriented architecture with clear separation of concerns. 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 a relational database (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 a message queue (Kafka or SQS) to decouple inventory updates from search reindexing, ensuring eventual consistency without blocking booking transactions.

Step 3: Deep Dive on Inventory and Booking Flow

Walk through the core booking transaction in detail. 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 to acquire row-level locks. If every night has at least one room available, it decrements available_count for each date and inserts a row into the reservations table 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 the transaction. If payment fails or times out, it rolls back, returning inventory to the pool. Discuss how FOR UPDATE row locks prevent concurrent transactions from seeing stale availability, and how indexing on (hotel_id, room_type_id, date) ensures the range scan completes in milliseconds even with millions of inventory rows.

Step 4: Address Secondary Concerns

Cover remaining non-functional requirements. For scalability, partition the inventory table by date (monthly or quarterly partitions) to keep active queries performant and archive old data. Use read replicas for search-related queries that tolerate slight lag. For reliability, implement idempotency tokens on booking requests so retries do not double-charge or double-book. Use circuit breakers around payment gateway calls to fail fast and release inventory locks. For fault tolerance, explain how a failed database write should not leave orphaned assets -- if writing the reservation row fails, ensure that any thumbnails already uploaded to blob storage are cleaned up by a garbage collection job that reconciles blob storage against confirmed reservations. For latency, explain how caching popular searches in Redis with 5-minute TTLs reduces database load, and how precomputing min/max prices per hotel avoids aggregation queries. For consistency, describe how inventory changes publish events to Kafka; a consumer updates Elasticsearch, accepting eventual consistency in search results while guaranteeing strong consistency in the booking path.