Practice/JPMorgan Chase/Design a Hotel Booking System

Design a Hotel Booking System

System DesignMust

Problem Statement

Design a hotel booking system that allows users to search for hotels, make reservations, and manage bookings. The platform must serve as an online travel marketplace (think Booking.com or Expedia) where travelers search for accommodations by location and dates, compare room types and prices, and complete reservations with payment. Behind the scenes, the system must track nightly room inventory across thousands of properties, apply complex pricing rules that vary by date, occupancy, and demand, and prevent double-bookings when two users attempt to reserve the last available room simultaneously.

The core technical challenge is maintaining data integrity under high concurrency while delivering sub-second search latency. Search traffic dwarfs booking volume by orders of magnitude, requiring you to separate read-heavy discovery from write-heavy reservation transactions. The booking flow itself is a multi-step process spanning inventory holds, payment authorization, confirmation, and potential rollback -- each step with distinct consistency and durability requirements. Interviewers use this problem to test whether you can model real-world constraints in a relational schema, write correct SQL for availability and pricing, handle high-contention reservations with strong transactional semantics, and orchestrate multi-step workflows reliably.

Key Requirements

Functional

Hotel search -- Users filter properties by location, check-in/check-out dates, guest count, price range, and amenities, receiving results sorted by relevance, price, or rating
Pricing display -- Show accurate per-night rates, total cost breakdown including taxes and fees, and cancellation policy details before the user commits to a booking
Room reservation -- Process bookings with payment authorization, atomically update inventory to prevent double-booking, generate confirmation codes, and send confirmation emails
Booking management -- Allow users to view reservation history, modify dates when cancellation 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; achieve 99.9% uptime for booking transactions and graceful degradation for search during partial outages
Latency -- Return search results within 300 milliseconds 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_id, room_type_id, date, available_count) tuple to track nightly availability independently
Use database partitioning by date range to keep recent inventory queries fast as historical data accumulates
Separate room definitions (capacity, amenities, photos) from time-based inventory to avoid data duplication across dates
Index by (hotel_id, room_type_id, date) for efficient range scans when checking multi-night availability in a single query

2. Concurrency Control and Double-Booking Prevention

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 to serialize competing requests
Implement optimistic locking with version numbers if lock contention is too high, retrying on version mismatch with exponential backoff
Consider a two-phase approach: place a soft-hold on inventory with a short TTL (5 minutes) while the user completes payment, then convert to a 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 clear separation of concerns between your transactional database and 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, star rating, and price range
Precompute and denormalize availability flags (has_rooms_for_dates) in your search index, refreshing asynchronously from booking events via a message queue
Cache popular search queries and minimum prices per hotel in Redis with appropriate TTLs to reduce load on the search cluster
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 and season, occupancy levels add surcharges, taxes differ by jurisdiction, and promotional discounts apply conditionally. Interviewers want structured thinking about where pricing logic lives and how it stays performant.

Hints to consider:

Store base nightly rates in a pricing table keyed by (hotel_id, room_type_id, date_range, rate_amount) to support seasonal and event-based pricing
Apply occupancy modifiers (single vs. double occupancy surcharges), tax rates, and resort fees at query time in a dedicated pricing service
Cache computed prices for common search patterns (weekend stays in popular cities) to avoid recalculating on every search
Isolate pricing rules in their own service so business logic changes deploy independently from booking infrastructure

5. Multi-Step Booking Workflow

A booking is not 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 without distributed transactions.

Hints to consider:

Model bookings with a state machine (PENDING, PAYMENT_AUTHORIZED, CONFIRMED, CANCELLED) and use idempotency keys for safe retries at each step
Use a Saga or workflow orchestrator to coordinate: hold inventory, call payment gateway, finalize reservation, send confirmation email
Implement compensating transactions: if payment authorization succeeds but confirmation write fails, retry asynchronously rather than rolling back the charge
Store holds with expiration timestamps and run a background reaper job that releases expired holds to reclaim inventory for other users

Practice/JPMorgan Chase/Design a Hotel Booking System

Design a Hotel Booking System

System DesignMust

Problem Statement

Key Requirements

Functional

Hotel search -- Users filter properties by location, check-in/check-out dates, guest count, price range, and amenities, receiving results sorted by relevance, price, or rating
Pricing display -- Show accurate per-night rates, total cost breakdown including taxes and fees, and cancellation policy details before the user commits to a booking
Room reservation -- Process bookings with payment authorization, atomically update inventory to prevent double-booking, generate confirmation codes, and send confirmation emails
Booking management -- Allow users to view reservation history, modify dates when cancellation 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; achieve 99.9% uptime for booking transactions and graceful degradation for search during partial outages
Latency -- Return search results within 300 milliseconds 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

Hints to consider:

Maintain an inventory table with rows for each (hotel_id, room_type_id, date, available_count) tuple to track nightly availability independently
Use database partitioning by date range to keep recent inventory queries fast as historical data accumulates
Separate room definitions (capacity, amenities, photos) from time-based inventory to avoid data duplication across dates
Index by (hotel_id, room_type_id, date) for efficient range scans when checking multi-night availability in a single query

2. Concurrency Control and Double-Booking Prevention

Hints to consider:

Use pessimistic row-level locking (SELECT FOR UPDATE) when decrementing inventory during booking transactions to serialize competing requests
Implement optimistic locking with version numbers if lock contention is too high, retrying on version mismatch with exponential backoff
Consider a two-phase approach: place a soft-hold on inventory with a short TTL (5 minutes) while the user completes payment, then convert to a 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

Hints to consider:

Use Elasticsearch for full-text search on hotel names and descriptions, geospatial queries by location, and faceted filtering by amenities, star rating, and price range
Precompute and denormalize availability flags (has_rooms_for_dates) in your search index, refreshing asynchronously from booking events via a message queue
Cache popular search queries and minimum prices per hotel in Redis with appropriate TTLs to reduce load on the search cluster
Paginate results and fetch detailed availability only for hotels on the current page, not the entire result set

4. Pricing Calculation and Dynamic Rates

Hints to consider:

Store base nightly rates in a pricing table keyed by (hotel_id, room_type_id, date_range, rate_amount) to support seasonal and event-based pricing
Apply occupancy modifiers (single vs. double occupancy surcharges), tax rates, and resort fees at query time in a dedicated pricing service
Cache computed prices for common search patterns (weekend stays in popular cities) to avoid recalculating on every search
Isolate pricing rules in their own service so business logic changes deploy independently from booking infrastructure

5. Multi-Step Booking Workflow

Hints to consider:

Model bookings with a state machine (PENDING, PAYMENT_AUTHORIZED, CONFIRMED, CANCELLED) and use idempotency keys for safe retries at each step
Use a Saga or workflow orchestrator to coordinate: hold inventory, call payment gateway, finalize reservation, send confirmation email
Implement compensating transactions: if payment authorization succeeds but confirmation write fails, retry asynchronously rather than rolling back the charge
Store holds with expiration timestamps and run a background reaper job that releases expired holds to reclaim inventory for other users