Katkat
Back

Design a Low-Latency Hotel Room Availability System

RampSoftware Engineer · Technical Screen
MediumSoftware EngineerTechnical ScreenSystem Design

Last updated

Design a high-throughput, low-latency room availability and reservation service that prevents double-booking while maintaining fast read times under heavy search traffic.

Scenario

Corporate travel platforms like Ramp Travel allow corporate clients to search and book hotel inventory across thousands of partner properties. During high-demand travel periods, search traffic dwarfs booking traffic by several orders of magnitude. The system must display near-real-time room availability while strictly preventing double-booking when multiple employees attempt to reserve the same room simultaneously.

Design a hotel room availability and temporary hold service.

Requirements

Functional Requirements

  • Search Availability: Users query for available room types for a given hotel and date range (check_in, check_out).
  • Reserve Hold: Users can place a temporary hold on a room type for 10 minutes while completing checkout.
  • Confirm Booking: Finalize the reservation upon payment confirmation; release the hold if payment fails or time expires.
  • Inventory Management: Hotel managers can update total available rooms per date and room type.

Non-Functional Requirements

  • Low Latency: p99 search latency under 50ms; reservation hold latency under 150ms.
  • Consistency & Correctness: Zero double-bookings. Strict consistency during the hold/booking phase.
  • Availability: 99.99% uptime for searches; graceful degradation if booking or partner sync is degraded.

Scale & Traffic Estimates

  • Total Hotels: 50,000 properties worldwide.
  • Booking Window: Up to 365 days in advance.
  • Search Traffic: 50,000 queries per second (QPS) at peak.
  • Hold/Booking Traffic: 500 reservation holds per second at peak (100:1 read-to-write ratio).

What Your Solution Should Cover

  • API Design: Core endpoints for availability check, hold creation, and booking confirmation.
  • Data Model & Storage: Relational vs. NoSQL choice, schema design for daily inventory tracking, and indexing strategy.
  • High-Throughput Read Architecture: Caching strategies (Redis, materialized daily views) and how cache invalidation or TTL is managed.
  • Concurrency Control: How to handle concurrent holds on the last remaining room (distributed locks, atomic DB updates, conditional writes).
  • Failure Modes: Expired hold cleanup and network partition behavior between payment and reservation systems.

Hints

Hint 1

Model inventory at the date-and-room-type level rather than as individual unique room IDs until actual physical check-in.

Hint 2

Use atomic decrements with conditional checks (e.g., `UPDATE inventory SET available = available - 1 WHERE available > 0`) or Redis Lua scripts to eliminate race conditions without heavyweight distributed locks.

Hint 3

Decouple expired hold cleanup from user-facing read paths using TTL-based Redis key expiration notifications or scheduled reconcilers.

Follow-up questions

  • How would you handle multi-night stays efficiently without suffering from distributed transaction overhead across 14+ daily inventory rows?
  • If hotel inventory is synchronized from external global distribution systems (GDS) with eventual consistency, how do you handle overbooking discrepancies?
  • How does your caching layer avoid cache stampede (thundering herd) when a popular conference causes thousands of users to query the same hotel simultaneously?