Skip to content

How a Booking.com-like travel agency might evolve

Thousands of searches for every booking, prices and availability owned by hundreds of thousands of external suppliers, and every pixel decided by an experiment. How look-to-book ratios, availability caching, supplier integrations and A/B testing shape an OTA.

The user problem and the hard parts

A traveller wants to compare many places for their dates, see real prices, and book with confidence that the room exists. An OTA (Online Travel Agency) does not own any rooms: it shows inventory that belongs to hotels, chains and wholesalers, and earns a commission.

The hard engineering problems:

  • Look-to-book ratio: for every booking there may be thousands of searches. Read traffic is orders of magnitude larger than write traffic, and each search is expensive (dates × room types × rate plans × occupancy).
  • Availability caching: prices and availability live in supplier systems. You cannot call every supplier on every search, so you cache, and caches go stale.
  • Supplier integrations: hotels connect through their own extranet, channel managers, or chain CRS (Central Reservation System) APIs, each with different formats, rate limits and reliability.
  • Experimentation culture: almost every change ships as an . The architecture must make running thousands of concurrent experiments safe and cheap.
  • Booking correctness: when the guest books, the room must be confirmed by the supplier, the price honoured, and the payment model (pay now vs pay at hotel) respected.
Look-to-book
Searches (or availability requests) per confirmed booking. Hundreds to thousands in travel, which is why search is engineered as a separate, cache-heavy system.
Extranet
The OTA's own web portal where a hotel edits rates and availability directly. Data entered here is first-party and fresh.
Channel manager
Third-party software that pushes a hotel's rates and availability to many OTAs at once. The OTA receives pushes and must apply them in order.
Rate parity
Contractual or commercial pressure to show the same price across channels. Stale caches can show a different price than the hotel's own site.

How the architecture might evolve

A Booking.com-like online travel agency

A plausible architecture for a large online travel agency at each scale. Booking.com is publicly known for its strong experimentation culture; the systems described here are illustrative.

  1. 1
    Stage 1 · Regional OTA
    5k hotels · 1M searches/day
    Server-rendered web monolithRelational database for hotels, rates, availabilityExtranet for hotels to load ratesEmail confirmations to hotels

    With first-party data entered by hotels, availability lives in your own database. Search queries it directly with good indexes. Confirmations by email are acceptable at this volume.

  2. 2
    Stage 2 · National leader
    100k hotels · 50M searches/day
    Many read replicas for searchPrecomputed availability/price grid per hotel per nightChannel manager push APIsQueue + workers to apply supplier updatesA/B testing framework in the monolith

    Search moves to and a denormalised grid so the primary only takes writes. Supplier updates are applied asynchronously and in order per hotel, so a burst of pushes doesn't lock the database.

  3. 3
    Stage 3 · Global OTA
    1M+ properties · billions of searches/month
    Dedicated availability search service with in-memory gridLayered caches (per-request, per-node, distributed)Supplier gateway with per-supplier rate limits, retries and circuit breakersEvent stream of rate/availability changesExperimentation platform with central metrics

    The search tier scales on its own and holds data in memory. Cache layering absorbs the look-to-book ratio. A supplier gateway isolates the rest of the system from slow or failing partners.

  4. 4
    Stage 4 · Travel platform
    Stays, flights, cars, attractions
    Multi-region search with regional cachesReal-time price checks only at the last steps of the funnelData platform for ranking and pricing MLShared booking and payment services across verticals

    Each vertical has a different supplier model, but booking, payments and customer service can be shared. Live supplier calls are reserved for where correctness matters most.

Cheap reads, careful writes

A plausible architecture for Stage 3 might look like this. The funnel gets more expensive and more accurate at each step: search uses caches, the hotel page refreshes, the booking calls the supplier.

Click a component

Click any component to see what it does.

Deep dive: architecture for experimentation

Booking.com is publicly known for running a very large number of concurrent experiments and letting most teams ship changes as tests. Whatever the company, that culture has architectural consequences:

  • Feature flags everywhere: every change can be toggled per visitor without a deploy.
  • Deterministic assignment: hash(visitor, experiment) so assignment is stateless and consistent across servers.
  • Exposure logging: record who actually saw the variant, not just who was assigned. Analysing assigned-but-not-exposed users dilutes results.
  • Guardrail metrics: every test also monitors errors, latency and cancellations, so a "winning" variant that slows the page is caught.
  • Statistics as a platform: a central team owns the maths (sample sizes, , multiple-testing corrections). Product teams should not each reinvent it.
  • Cleanup: dead flags are . Remove losing variants quickly.

Engineering trade-offs

Live supplier calls on every search

  • Always fresh prices
  • No cache invalidation
  • Latency of the slowest supplier
  • Suppliers rate-limit or block you
  • Cost per search
Choose when: Small number of suppliers with fast APIs, or only for the final booking step.

Push-based cached grid

  • Millisecond search
  • Suppliers send only changes
  • Stale data when pushes are delayed or lost
  • Reconciliation jobs needed
Choose when: High look-to-book ratios and suppliers that support push.

Ship by opinion

  • Faster to decide
  • No statistics infrastructure
  • Many changes have zero or negative effect and nobody knows
  • Arguments decided by seniority
Choose when: Very low traffic, where tests could never reach significance.

Ship by experiment

  • Measured impact
  • Teams can act autonomously within guardrails
  • Flag complexity and code paths multiply
  • Optimises measurable short-term metrics
Choose when: Enough traffic to detect small effects, and a funnel with clear success metrics.

Practical exercise

The price changed at checkout

A chain's channel manager sometimes sends rate updates out of order: an update made at 10:01 arrives before one made at 10:00. Travellers see the wrong price in search, and some bookings fail at supplier confirmation. How do you make updates safe and limit the damage?