Design the backend for a hotel reservation system that lets travellers search hotels by city and date range, see live nightly availability and prices, hold a room while they pay, and confirm a booking (think a mainstream online travel booking site).

Operating context. The platform aggregates inventory for roughly 200k hotels across many regions; each hotel exposes a handful of room types, and availability is tracked per room-type per calendar night. Traffic is read-heavy and bursty: search and availability lookups run around 8000 requests/sec at steady state and spike to 40000/sec during holiday sales, while actual bookings are far rarer at about 200 writes/sec with sharp contention on scarce dates (a single popular hotel on a long-weekend night can draw hundreds of concurrent buyers for its last few rooms). Property managers (and upstream channel managers) continuously push rate and inventory updates that must reflect in search within seconds. The read path targets p99 < 250 ms; the booking-confirm path may be slower but must never sell the same physical room twice.

Out of scope. Payment-gateway internals (assume a payment service returns success/failure), loyalty points and promo-code math, hotel onboarding and KYC, review/ratings storage, and the recommendation ranking model. Assume separate teams own those.

What to produce. A high-level architecture covering: the request paths (search/filter, availability read, hold, confirm, cancel); the inventory data model and how per-night counts are partitioned; how a hold reserves capacity and how confirm avoids double-booking under contention; the search + filtering strategy (geo/date/price/amenities) and how it stays fresh as rates and inventory change; the cancellation and refund flow including how released inventory re-enters the calendar; and how rate/inventory sync from property and channel managers propagates to the search index. Sketch the major components and the request flow between them; we will probe specifics during checkpoints.