Hotel Reservation

01What does a traveler actually get from search?

Search takes a property, a check-in/check-out range, and a guest count, and returns room types with a total bookable price — availability and rate together, because an open room without a price is not a result anyone can book.

02Are we booking a specific room or a room type?

A room type: the hotel sells one of its 40 Deluxe Queens, not room 312 — inventory is a per-night counter per room type, and the front desk assigns physical rooms at check-in.

03What happens between “book now” and “confirmed”?

Checkout places a hold that reserves the count for every night of the stay for about 10 minutes while payment runs; if payment fails or the guest walks away, the hold expires and the counts return by themselves.

04Can guests cancel or change dates, and does it cost them?

Yes — cancellation is normal business, governed by the rate plan’s free window and fees, and a date change re-validates availability for the new range before the old nights are released.

05Do we ever sell more rooms than physically exist?

Deliberately, yes: each room type carries a configured oversell margin (sell 105 of 100) tuned to historical no-show rates, plus a walk flow — relocate and compensate — for the rare night everyone shows up.

06The confirm call times out and the app retries — two bookings?

No: confirm carries an idempotency key, so any retry of the same attempt maps to the same reservation and a single charge.

01How fresh does search availability have to be?

Seconds-stale is acceptable for search — the booking transaction checks the true counters, so a stale cache can only cost an apology at checkout, never an oversell past policy.

02Two guests grab the last room-night at the same instant?

Exactly one succeeds: the decrement is conditional and atomic per night row, so there is no read-then-write gap for two bookings to share the last room.

03A 7-night stay where one middle night is full — partial booking?

Never: all nights of a stay commit in one transaction — all seven counters decrement or none do, because a guest holding nights 1-4 and 6-7 is corrupt data, not a booking.

04How lopsided is read traffic versus write traffic?

Roughly 200 searches for every booking, so reads scale on caches and replicas while writes stay on one small, strongly consistent counter store.

05A confirmed reservation can never vanish?

Correct: a reservation is durable — synchronously replicated SQL — before the guest sees a confirmation number, because a lost booking surfaces as a guest standing in a lobby at midnight.