Practice/Meta/Design a Hotel Booking System

Design a Hotel Booking System

System DesignMust

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'll 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'll scale read-heavy search workloads independently 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. Pricing Calculation and Dynamic Rates

Hotels apply complex pricing rules—base rates vary by date, occupancy rates add surcharges, taxes differ by jurisdiction, and promotions apply discounts. Interviewers want structured thinking about where pricing logic lives.

Hints to consider:

• Store base nightly rates in a pricing table keyed by (hotel, room_type, date_range, rate) to support seasonal and event-based pricing
• Apply occupancy modifiers (single vs. double occupancy surcharges) and tax rates at query time or in a pricing service layer
• Cache computed prices for common search patterns (e.g., weekend stays) to avoid recalculating on every search
• Consider a pricing service that encapsulates rules and can be updated without deploying booking logic changes

5. Multi-Step Booking Workflow

A booking isn't atomic—it involves inventory hold, payment authorization, reservation creation, confirmation delivery, and potentially rollback if payment fails. Interviewers probe how you maintain consistency across these steps.

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