Marketplaces, an interactive architecture walkthrough
Hotel booking system: how the architecture works
How a hotel booking system searches cached availability, books every night of a stay in one transaction, and holds rooms while payment completes.
This is a learning explainer based on public engineering writing and general design practice. It is simplified, it is not the actual architecture of any company, and it may be inaccurate.
Interactive diagram
Overview
A hotel booking system lets guests search hotels by place and dates and book a room type for a range of nights, while hotels manage rates and how many rooms they sell. Search and booking are built differently on purpose: search reads cached availability and a search index and can be slightly stale, while booking runs a database transaction that must never sell a room twice.
Inventory is stored as a count per room type per night, so a multi-night stay checks and decrements every night in one transaction, and a sold-out night rolls back the whole booking. A booking first becomes a hold with an expiry, payment is authorised, and the hold is confirmed or released. Inventory changes are published as events to refresh caches and to sync with other sites selling the same rooms. This is a simplified learning design, not any company's production system.
Trade-offs and what changes at scale
Strong consistency is used only where money and rooms change hands; everything shown during search is eventually consistent, which keeps search fast but means a room can disappear between search and checkout. Holds protect the guest during payment but tie up rooms, so their length is a business choice. Selling the same rooms through several channels makes small overbooking windows hard to remove completely, which is why some hotels keep a buffer. At larger scale inventory is partitioned by hotel, since a booking never spans hotels.
How it works, step by step
The walkthrough above, as text. Each step lights up the components named under it.
A guest searches for a city, dates and number of guests, and the Search Service finds matching hotels by location and amenities in the Hotel Index. The index holds descriptive data that changes rarely, not availability.
Rooms left per night come from the Availability Cache and prices from the Pricing Service. Search results can be a little stale, because the real check happens at booking time.
When the guest chooses a room, the Booking Service starts a transaction for every night of the stay. Search is optimised for speed; booking is optimised for never selling the same room twice.
In one transaction the service decrements the room-type count for each night in the Inventory DB, with a condition that the count stays at or above zero. If any night is sold out the whole transaction fails, so a partial stay is never booked.
The same transaction inserts a hold into the Reservation DB with a 15-minute expiry. For specific room numbers, an exclusion constraint on the stay's date range rejects two overlapping reservations for the same room at the database level.
The Booking Workflow authorises the card with the Payment Provider and then marks the reservation confirmed. If payment fails, it cancels the hold and returns the nights, the compensating step of a saga.
The Hold Expiry Worker finds holds whose time has passed without payment and gives their nights back to inventory. Without it, abandoned checkouts would slowly make a hotel look sold out.
Every inventory change is published to Inventory Events, and the Cache Updater refreshes the Availability Cache from them. Search catches up within seconds without querying the inventory database.
Hotels also sell rooms on other sites, so the Sync Worker pushes availability to the Channel Manager and applies bookings made elsewhere. Rooms sold on two sites in the same seconds are the main source of overbooking, so these updates are processed promptly.
Hotel staff use the Hotel Extranet to change rates and how many rooms of each type are for sale. Those changes write to the Inventory DB and flow out through the same events.
A confirmed booking triggers the Notification Service to send the confirmation and later reminders. Emails are sent after the commit, so a guest never gets a confirmation for a booking that rolled back.
After checkout, the Reviews Service accepts a review only if the Reservation DB shows a completed stay. Bookings also replicate to the Analytics Store to measure the search-to-booking funnel.
Sequence diagram
The same walkthrough as a UML sequence diagram, one lane per layer or group (20 components in all), left to right in the order a request reaches them, numbered by step. A loop on a lane is a step that stays inside that group. Solid arrows are synchronous calls, dashed are asynchronous.
Key components
Clientslayer
- Channel Manager: syncs inventory with other sites
- Guest App: search, book, manage stays
- Hotel Extranet: rates, rooms, availability
Searchdomain
- Availability Cache: rooms left and price per night (redis)
- Hotel Index: hotels, amenities, geo points (elasticsearch)
- Pricing Service: rate plans, taxes, discounts
- Search Service: location, dates, guests, filters
Bookingdomain
- Booking Service: hold, confirm, cancel
- Booking Workflow: hold, pay, confirm, or compensate
- Hold Expiry Worker: releases unpaid holds
- Inventory DB: room-type counts per night (postgresql)
- Payment Provider: card authorisation
- Reservation DB: bookings, guests, date ranges (postgresql)
Inventory Syncdomain
- Cache Updater: refreshes availability cache
- Inventory Events: availability and rate changes (kafka)
- Sync Worker: pushes and pulls partner inventory
After Bookingdomain
- Analytics Store: search-to-book funnel (clickhouse)
- Notification Service: confirmation and reminder emails
- Reviews Service: verified-stay reviews
API Gateway
- API Gateway: auth, rate limits, bot protection
Sources
Public writing this explainer draws on. Read these for what the real systems actually do.
Make it yours
Copy this diagram and its walkthrough into your own workspace, then change anything: swap Postgres for DynamoDB, add a cache, rewrite the narration. Free, and it uses no AI credits.
Related walkthroughs
- Ticket booking with seat reservationHow a ticketing system sells each seat once under heavy demand: waiting room, cached seat map, time-limited holds, conditional updates and safe payment.
- E-commerce checkout and inventoryHow an online store turns a cart into an order: stock reservation, idempotent payment, a saga with compensation, and reliable order events.
- Ride-hailing platformHow a ride-hailing platform streams driver locations, matches a rider to a nearby driver, prices the trip with surge, and takes payment.
This is a learning explainer based on public engineering writing and general design practice. It is simplified, it is not the actual architecture of any company, and it may be inaccurate. Real systems differ in the details. Browse the library.