Design hotel booking (Airbnb / Booking.com)

The natural unit of hotel inventory is a room type on a night, not a specific room: a hotel says it has 12 deluxe rooms, and assigns room 304 at check-in. So store one row per (room_type_id, night) with total, booked and held counts. Homes on Airbnb are the special case where total = 1. A stay of N nights must reserve all N rows or none. Keep all inventory of one property on one shard, so a booking is a local transaction, not a distributed one. Inside it, a single conditional UPDATE over the N night rows with the check total - booked - held >= rooms, then verify the affected row count equals N. This is safe under concurrency because each row update takes a row lock and re-evaluates the condition; two guests racing for the last room cannot both succeed. Avoid read-then-write in application code without locks. Holds with a short expiry protect the payment window; a sweeper releases expired holds, and confirmation converts held to booked. An Idempotency-Key on the booking request makes retries safe. For hot properties during peak, contention is per row and short, so throughput is fine; no global locks are needed.

Searching 'available in Goa from 20-23 Dec' needs geo, filters and per-night availability together. Pure SQL across billions of inventory rows is too slow for a geo search, and Elasticsearch is not a source of truth. The common approach is a denormalised availability index: for each room type, store availability bits or minimum available count for the next ~180-365 nights, plus the lowest nightly price, inside the property document (or a side index joined by property_id). A query checks the nights of the stay with a script or pre-computed fields. CDC from the inventory tables updates these fields within seconds. Because the index can be slightly stale and prices depend on the exact stay (length-of-stay discounts, taxes), re-check the top results against the availability service before showing them, and always check again at booking. Cache popular searches (city + dates) in Redis for a minute. Map search uses geo bounding boxes with a geohash-based cluster aggregation for zoomed-out views. Ranking blends price, rating, distance, and predicted conversion, and must not show unavailable properties, which is the most annoying failure for users.

Most hotels sell the same rooms on many sites at once through a channel manager connected to their property management system (PMS). We hold a copy of their availability, not the truth. Two sites can sell the last room within the same few seconds before updates propagate. Mitigations: push our bookings to the channel manager immediately (async but fast, with retries and an outbox), accept availability updates through a high-throughput partner API, and apply updates with version or timestamp checks so an old message cannot overwrite a newer one. Some hotels give each channel a fixed allotment of rooms, which removes the race at the cost of flexibility. When an overbooking happens anyway, the process matters: detect it quickly (reconciliation with the PMS), contact the guest, and 'walk' them to an equal or better hotel at the platform's cost. Say clearly in the interview that our system guarantees no double-booking within our own inventory; across channels, the guarantee depends on the partner, and the design minimises the window.

Computing availability by counting overlapping bookings per query is flexible but slow and hard to lock correctly. Per-night counter rows make availability a simple read and make booking a conditional update. The cost is many rows (billions), which is fine with sharding and since most are cold.

Holds prevent a guest from paying for a room someone else just took, but holds can lock inventory for bots or abandoned checkouts. Use short TTLs (~10 min), per-user hold limits, and release on payment failure.

Indexing availability in Elasticsearch makes search fast but stale by seconds. Re-checking the top results and the booking-time transaction keeps the user experience right. Trying to make search strongly consistent would make it far too slow.

Pay-at-hotel converts better in India for some segments but has more no-shows. Require card guarantee or a small prepaid amount for high no-show segments, and let hotels choose policy.

Long weekends drive 5x search. Scale Elasticsearch replicas, cache popular city-date searches for 30-60 s, and cap the re-check to the first page.

Hotels push rate changes for hundreds of dates at once. Batch updates per property, collapse multiple updates for the same row in the queue, and rate-limit per partner.

A popular resort during a flash deal has many concurrent bookings on the same rows. Row-level locks are short, so throughput is OK; queue requests per property if lock waits grow.

The confirm transaction tries to book the nights again. If available, confirm; if not, refund automatically and offer alternatives. Holds should be longer than the payment timeout to make this rare.

The outbox keeps the event; the notifier retries with backoff. Bookings not acknowledged by the hotel within a few minutes raise an alert, and reconciliation with the PMS catches mismatches.

If CDC lags, search shows stale availability. Re-check and booking-time checks prevent wrong bookings; monitor CDC lag and fail over to a lighter live query if lag is large.