System Design: Design Booking.com — Hotel Search, Availability, Dynamic Pricing, Overbooking, Cancellations, Reviews

Booking.com connects 28+ million accommodation listings with hundreds of millions of travelers. Designing an online travel agency (OTA) tests your understanding of: geospatial search with complex filtering, real-time availability management across multiple distribution channels, dynamic pricing, and the overbooking strategies that maximize occupancy. This guide covers the hotel booking architecture for system design interviews.

Hotel Search

The core search query: “find available hotels in Paris for Aug 10-15, 2 adults, sorted by best value.” This combines: (1) Geospatial search — hotels in Paris (city boundary or radius from city center). Elasticsearch geo_bounding_box or geo_polygon. (2) Availability filtering — hotels with at least one room available for ALL nights of the stay. This is the hardest part (see Availability section below). (3) Guest capacity — rooms that accommodate 2 adults. (4) Complex filters — star rating, price range, guest rating (8+), amenities (pool, wifi, parking), property type (hotel, apartment, hostel), meal plan (breakfast included), cancellation policy (free cancellation). All indexed in Elasticsearch. (5) Sorting — by price (lowest first), by rating (highest first), by distance, or by “our recommendations” (ML-ranked balancing value, popularity, and commission). Autocomplete: as the user types a destination, suggest: cities, regions, specific properties, landmarks, and airports. Pre-computed suggestion lists with popularity weighting. “Par” -> “Paris, France (12,345 properties)” as the top suggestion. Map view: search results displayed on an interactive map. Each result is a pin with price. Panning the map triggers a new search for the visible viewport. Clustering: when zoomed out, cluster nearby hotels into a single icon showing the count and price range.

Availability and Inventory Management

Availability is the most complex component. Each property has multiple room types. Each room type has: a finite inventory (e.g., 10 Standard Double rooms), per-night pricing, and restrictions (minimum stay, closed-to-arrival on certain days, max occupancy). Availability check for a 5-night stay: the room must have available inventory on ALL 5 nights. If 4 of 5 nights have availability but one is sold out: the room is not bookable for this stay. Data model: room_night: property_id, room_type_id, date, total_inventory, booked_count, available_count (= total – booked), price, restrictions. For 28M listings * average 3 room types * 365 days = ~30 billion room-night records. Storage: partitioned by property_id for efficient per-property queries. Availability for search: checking 30 billion records for every search is too slow. Optimization: (1) Pre-compute availability summaries per property per date range (rolled up from room-night data). Index in Elasticsearch: available_from, available_to, min_price per date range. (2) Two-phase search: broad search in Elasticsearch (geospatial + filters + approximate availability), then detailed availability verification for the top results against the authoritative room-night database. Overbooking: properties sometimes sell more rooms than they have (expecting cancellations). The system allows booking beyond 100% availability up to a configurable overbooking threshold (e.g., 105%). If a guest arrives and no room is available: the hotel must relocate them (walk the guest to a comparable or better property). Revenue management: overbooking maximizes occupancy and revenue but carries the cost of relocation.

Booking Transaction

When a guest clicks “Reserve”: (1) Availability re-check — verify the room is still available for all selected dates (real-time check against the authoritative inventory). Between the search results and the booking click: another guest may have booked the last room. (2) Price confirmation — recalculate the total price (nightly rates * nights + taxes + fees). Display to the guest for confirmation. Prices may change between search and booking. (3) Guest details — collect: name, email, phone, special requests, and payment information. (4) Payment — two strategies: (a) Pay now: charge the full amount immediately. Lower cancellation rates but some guests prefer flexibility. (b) Pay at property: guarantee with a credit card (authorization hold for first night). The property charges at check-in/check-out. Higher cancellation rates but more bookings. (5) Inventory decrement — atomically decrement available_count for each night. If any night fails (sold out during the transaction): roll back all nights and inform the guest. Use: UPDATE room_nights SET booked_count = booked_count + 1 WHERE property_id = X AND room_type_id = Y AND date IN (…) AND available_count > 0. (6) Confirmation — generate a booking reference, send confirmation email to guest and notification to property, update availability in the search index. Multi-channel inventory: the same room is sold on Booking.com, Expedia, and the hotel direct website. A channel manager (SiteMinder, RateGain) syncs availability across all channels in real-time. When a room is booked on Booking.com: the channel manager decrements inventory on all other channels within seconds.

Dynamic Pricing

Hotels adjust prices daily based on: (1) Demand — high demand (events, holidays, weekends) = higher prices. Low demand (midweek off-season) = lower prices to attract bookings. (2) Occupancy — as rooms fill up: remaining rooms are priced higher (scarcity premium). When occupancy is low: prices drop to fill rooms. (3) Competition — monitor competitor prices (other hotels in the area on the same dates). Price relative to the market. (4) Lead time — bookings far in advance are cheaper (the hotel wants to fill a base level of occupancy). Last-minute bookings: either very cheap (desperate to fill) or very expensive (scarcity). Revenue management system (RMS): an ML model predicts optimal prices per room type per date. Features: historical demand patterns, local events (concerts, conferences, sports), day of week, season, current occupancy, competitor prices, and time until check-in. The model optimizes: RevPAR (Revenue Per Available Room) = occupancy rate * ADR (Average Daily Rate). A hotel with 100 rooms can earn more with 80% occupancy at $200/night ($16,000) than 100% at $150 ($15,000). The RMS finds the price that maximizes total revenue considering demand elasticity. Booking.com perspective: the OTA does not set prices (the hotel does), but it influences through: visibility (better-priced listings rank higher in search), promotions (Genius discounts for loyal guests), and dynamic commission adjustments.

Cancellations and Modifications

Cancellation policies: (1) Free cancellation until X days before check-in (most common on Booking.com). After the deadline: a penalty applies (typically first night or a percentage). (2) Non-refundable — cheaper rate, no cancellation without penalty. Attracts price-sensitive guests. (3) Flexible — full refund until check-in day. Premium rate. Policy enforcement: when a guest cancels, the system checks: is it within the free cancellation window? If yes: full refund, release inventory. If no: calculate the penalty, charge the guest card, and release the remaining nights inventory. The property keeps the penalty amount. Modification: change dates or room type. Treated as: cancel the old booking + create a new booking. If the new booking is more expensive: charge the difference. If cheaper: refund the difference. Availability must be checked for the new dates. No-shows: the guest does not arrive and does not cancel. The property charges a no-show penalty (typically first night). The room is released for the remaining nights (may be sold to walk-in guests). No-show detection: the property marks the booking as no-show via their extranet after check-in time passes. Impact on future search: high cancellation rate properties may be deprioritized in search (unreliable availability frustrates guests who find their “confirmed” hotel is actually full).

{“@context”:”https://schema.org”,”@type”:”FAQPage”,”mainEntity”:[{“@type”:”Question”,”name”:”How does hotel availability work for multi-night bookings?”,”acceptedAnswer”:{“@type”:”Answer”,”text”:”A room must be available on ALL nights of the stay. Data: room_night records (property_id, room_type_id, date, total_inventory, booked_count, available_count, price). For 28M listings * 3 room types * 365 days = ~30 billion records. Two-phase search: (1) Elasticsearch pre-filter with approximate availability (pre-computed available date ranges, min_price) + geospatial + filters. Returns candidates quickly. (2) Detailed verification against the authoritative room-night database for displayed results. Booking: atomically decrement available_count for each night — UPDATE room_nights SET booked_count = booked_count + 1 WHERE … AND available_count > 0. If any night fails: roll back all. Multi-channel: the same room is sold on Booking.com, Expedia, and direct. A channel manager syncs availability across all channels in real-time (seconds after a booking on any channel).”}}]}
Scroll to Top