Hotel Reservation (Booking.com)

01Whose rooms are these — do we own any inventory?

None — every room belongs to an independent supplier hotel that also sells through its own site and rival channels, so our availability data is a cache of someone else’s truth and is stale the moment we write it.

02What does a guest search actually return?

City plus dates plus guests returns ranked hotels with price and availability served entirely from our cached snapshot — fresh enough to browse and compare, never trusted enough on its own to take money against.

03What exactly happens when the guest clicks book?

The system re-asks the real supplier before committing: revalidate availability and price live, reserve with the supplier, charge the guest, then confirm — a saga where the supplier’s answer at each step, not our cache, is the truth.

04How do thousands of different hotel systems feed us their rooms and prices?

One integration layer normalizes heterogeneous channel-manager and PMS (property management system — the hotel’s own front-desk software) APIs into a single internal availability-and-rate model, taking push webhooks from suppliers that support them and scheduling polling for the long tail that do not.

05The cache said available but the hotel says no — then what?

A rejected booking is a designed flow, not an error page: tell the guest honestly, correct the cache immediately so the same lie is not shown again, and offer comparable rooms at a similar price in one tap.

06Can guests cancel, and whose rules apply?

Yes, under the rate’s own cancellation policy: cancel runs as another saga leg — cancel with the supplier first, refund second — because the supplier’s books are the system of record and our booking row only mirrors them.

01How fast must search be, given suppliers answer in hundreds of milliseconds?

Search answers in about 300-500 ms at p99 by never touching a supplier in the read path — every result comes from the cached availability index, which is exactly why that cache exists.

02How stale can the cache be before it hurts?

Staleness is a budget, not a bug: minutes-stale is acceptable while the booking-rejection rate stays under roughly 1-2%, and freshness spend is tiered — hot properties refresh in about a minute, the long tail in about an hour.

03What must never go wrong in the money path?

A guest is never charged without a supplier confirmation and never double-booked by us: every saga step is idempotent, every failure has a compensating action, and the supplier’s reply is the deciding vote.

04One big supplier goes down — does the whole city search suffer?

Supplier failures stay isolated behind the feed layer: a dead feed means that hotel’s data ages (and its confidence drops) while search stays fast and every other property is untouched.

05The price moved between search and checkout — what does the guest pay?

Never a silent price difference: checkout re-quotes against the live supplier, and if the price moved the guest sees the new number and chooses — surprise charges destroy marketplace trust faster than any outage.