Katkat
Back

Design a Hotel Search and Reservation System

RipplingSoftware Engineer · Onsite
MediumSoftware EngineerOnsiteSystem Design

Last updated

Design an end-to-end hotel search and booking platform balancing high-throughput search with strictly consistent, transactional room inventory management across continuous date ranges.

Scenario

Design a global hotel discovery and reservation platform (similar to Booking.com or Expedia). The platform allows travelers to search for accommodations by location and dates, inspect real-time room quotes, reserve rooms with payment processing, and manage existing bookings.

Functional Requirements

  • Search & Discovery: Search hotels by geographic location, check-in/check-out dates, and guest capacity. Filter by amenities, price, and star rating.
  • Pricing & Quotes: Display accurate room quotes for selected date ranges, accounting for dynamic rates and taxes.
  • Inventory & Booking: Reserve specific room types across a continuous date range. Prevent overbooking (no night can exceed total room type capacity).
  • Lifecycle Management: Support reservation lookup, cancellation, and automated inventory release.
  • Payment & Idempotency: Safely integrate with external payment gateways, ensuring users are never double-charged or left with orphan reservations.

Non-Functional Requirements

  • Consistency vs. Availability: Prioritize high availability and low latency (< 200 ms) for search; prioritize strict consistency (ACID) and zero overselling for bookings.
  • Idempotency: All booking requests must be strictly idempotent.
  • Customer Privacy & Compliance: Sensitive payment information (PCI-DSS) and customer PII must be segregated and protected.

Scale Assumptions

  • Hotels & Rooms: 500,000 hotels worldwide, averaging 100 rooms each (~50 million total rooms).
  • Search Traffic: 50,000 read queries per second (QPS) at peak.
  • Booking Traffic: 500 booking transactions per second at peak (100:1 read-to-write ratio).
  • Booking Window: Reservations can be made up to 365 days in advance.

What Your Design Should Cover

  1. API Design: Core endpoints for search, room holds, booking confirmation, and cancellation.
  2. Data Model: Schema for hotels, room types, daily inventory records, and reservations.
  3. Inventory Management & Concurrency: Concurrency control mechanism (e.g., optimistic locking, row-level locks, distributed locks, or transactional decrement) across multi-night stays.
  4. Reservation Lifecycle & State Machine: Handling temporary inventory holds, hold expiration (TTLs), payment settlement, and asynchronous webhooks.
  5. Search Architecture: Caching strategies, handling stale search data, and syncing inventory/pricing changes into the search index.

Hints

Hint 1

Separate the read path (search and pricing engine) from the write path (reservation and inventory hold) using CQRS and an inverted search index like Elasticsearch.

Hint 2

Model inventory at the granularity of `(hotel_id, room_type_id, date)` with an explicit count of available rooms to make date-range checks standard transactional queries.

Hint 3

Use a two-phase reservation flow with a time-limited hold (e.g., 10-15 minutes) backed by an idempotency key before finalizing payment capture.

Follow-up questions

  • How does the system handle high contention on 'hot' inventory, such as a major conference where thousands of users compete for 50 remaining rooms?
  • If a third-party payment gateway webhook is delayed past the temporary hold expiration window, how does the system reconcile the state to avoid orphan charges or double bookings?
  • How would you handle room upgrades or partial date-range modifications on an existing confirmed reservation without risking inventory loss?