sydepsystem design atlas

Hotel Reservation System

Search availability across inventory, then confirm with a short hold.

IntermediateCommerce
ClientClientAPI GatewayNetworkingSearch ServiceComputeAvailability IndexStorageBooking ServiceComputeInventory DBStorage

A search service queries a denormalised availability index across properties and date ranges; confirming a booking places a short hold on the underlying inventory record before finalising payment.

When to use it

  • Search needs to be fast across a large, filterable inventory (dates, price, amenities)
  • There is a meaningful gap between 'shown as available' and 'confirmed booked' that needs a hold

Trade-offs

  • The availability index can drift from the source of truth and needs reconciliation
  • Holds that expire without confirmation must reliably release inventory back

Components used

Web AppAPI GatewayManaged App ServiceSearch IndexRelational Database

How it works

  • Search reads a denormalised availability index built for fast filtering by date range, location and attributes — never the transactional booking tables.
  • Booking re-checks true availability, places a hold, then confirms after payment, because search results are cached and may be seconds stale.
  • Availability is inherently a range problem: a room is bookable only if free for every night requested.

Used in the wild

  • Hotel and vacation-rental platforms.
  • Equipment and vehicle rental over date ranges.
  • Meeting-room and resource scheduling.

Good to know

  • Search-to-book conversion is low, often a few percent, so the read path handles far more traffic than the write path and is optimised completely differently.
  • Overbooking is frequently deliberate in this industry — expected cancellations are modelled and inventory is sold beyond capacity, which makes 'correctness' a business policy rather than a database constraint.