How to Build a Travel Search Engine: Architecture, Caching and Steps

A traveler searches Rome for three nights in May, sees a room at EUR 140 and clicks through, and the supplier now quotes EUR 165 or has no room left: the cached answer was fast and wrong.

How to build a travel search engine comes down to that trade: which answers may come from a cache, how old each one may be, and at which step the system must ask the supplier live.

The best-known travel metasearch engines, as they stand in October 2026:

• Google Hotels compares rates that hotels and OTAs send through Hotel Center, as paid Hotel Ads and free booking links, and since August 2026 it takes hotel bookings in AI Mode in the US.
• Kayak, owned by Booking Holdings, compares itineraries and prices from hundreds of travel sites in more than 60 countries and territories.
• Tripadvisor runs hotel metasearch inside its reviews platform, which the company now reports as its Hotels and Other segment, next to Viator and TheFork.
• trivago, controlled by Expedia Group, searches more than 7.0 million hotels and other accommodations in over 190 countries.
• Skyscanner, part of Trip.com Group, compares flights, hotels and car hire, and offers the same searches to partners through its travel APIs.

Importance of travel search engines

A travel search engine answers one question: what can this traveler book, for these dates and this party, and at what total price. It collects the answer from suppliers at the time of the search, rather than from pages it indexed last week, and that separates it from a web search engine.

Four kinds of business run one:

• An online travel agency searches the inventory it sells, and its search sits in front of a booking engine.
• A metasearch engine compares many sellers and sends the click to one of them; trivago and Tripadvisor's hotel business both earn mainly from click-based advertising.
• A hotel chain or an airline searches its own inventory on its own site.
• A bedbank or another B2B platform answers searches from agencies through an API.

Search is where the traveler decides, so it carries the traffic.

HBX Group, the bedbank behind Hotelbeds, reports 6.2 billion searches a day, and Expedia Group's B2B platform processes 21 billion API calls a day (company figures). Only a small share of those searches ends in a booking, so the cost of a search, more than the cost of a booking, decides the economics of the system.

If you are still deciding whether to run a metasearch business, our guide to travel meta search engines covers the commercial side, and the technical deep dive on meta search engines covers aggregation outside travel.

How a travel search request is answered

Every design passes a request through the same stages. The search service splits the query into supplier requests and checks the cache first. Fresh entries answer at once. Missing or stale ones go out to the suppliers in parallel: GDS and NDC connections for airline fares, bedbanks for net hotel rates, OTA partner APIs, and feeds that hotels push themselves.

The responses are normalized into one model, duplicates are merged and the list is ranked. When the traveler picks an offer, the system checks price and availability live before it books or redirects.

Travel search engines vs. classic search engines: comparison

A web search engine crawls documents, indexes them and ranks them, and a page indexed yesterday is usually still right today; our guide to building a search engine covers that architecture. A travel search engine keeps an index too, of hotels, airports and routes. The thing the traveler wants, a bookable price, is computed per query from inventory that keeps changing.

Perishable inventory and prices that depend on the whole query

A hotel room for 12 May is worth nothing on 13 May, and its price moves as the date approaches and rooms sell, which is the point of yield management. The price also depends on everything in the query: check-in date and length of stay, the number of adults, the ages of the children, the number of rooms, the traveler's market and currency. Change one child's age and the answer can change.

So availability has to be checked live before money moves. A cached price is fine on a results page and not at payment.

Look-to-book ratios and supplier rate limits

The look-to-book ratio is the number of searches per booking. On the UK hotel metasearch engine we rebuilt, 99 percent of about 200 million daily queries were read-only. Every search passed through to a supplier is a request the supplier pays to answer.

Suppliers protect themselves with limits. Hotelbeds caps an availability call at 2,000 hotels and, during certification, checks the number and order of calls a partner makes per booking. Expedia's Rapid Shopping API returns at most 250 properties per request. Supplier agreements can add request quotas or look-to-book ratios on top, so an engine that forwards every query to every supplier reaches a limit long before it runs out of hardware.

Combinatorics of flights and hotel rate plans

The numbers grow fast. Take an illustrative mid-size hotel with 6 room types and 8 rate plans (refundable or not, with or without breakfast, member rates, packages). Priced for 30 check-in dates, stays of 1 to 14 nights and 5 occupancies, it has 6 × 8 × 30 × 14 × 5 = 100,800 prices for one month, before currencies. A city has thousands of hotels.

Flights multiply differently. A return trip with 20 outbound and 20 inbound options makes 400 itineraries, and each segment carries several fare classes with rules about which combinations are allowed. This is why Google's ARI feed for hotels takes nightly rates, inventory and rules rather than finished prices: from those, Google computes prices for a wide range of advance purchase and length of stay values itself.

Fares, rate plans, cancellation rules, taxes and fees

Where a web page is text, a travel offer is a small contract: the room or fare, the rate plan and board, a cancellation policy with deadlines and penalties, taxes included and excluded, fees paid at the property, the payment model and the currency. Expedia's Shopping API returns refundability, cancellation penalties and a full price breakdown to meet each market's price display rules. Two offers with the same headline price can differ by a non-refundable rate or a resort fee, and the comparison has to show it.

Google's price accuracy policy puts a commercial cost on getting this wrong: the total price on the partner's booking page must be the same as the one shown on Google, and partners with poor scores lose auction position or have their ads and free booking links switched off.

The same hotel from five suppliers

One hotel arrives from a bedbank, two OTAs and its own channel manager, each with its own ID, spelling of the name, address format and coordinates. Without property mapping the results page shows the hotel four times. trivago's database of more than 7.0 million accommodations is gathered through OTAs, hotel chains, independent hotels and alternative accommodation providers, and merging such sources is a permanent job that runs whenever a supplier adds or edits a property.

Room types need the same treatment. A Deluxe King at one supplier and a Superior Double with one king bed at another may be the same room.

Benefits of a custom travel search engine

Most travel businesses should not build one at the start. A white label portal or a supplier's API gets a new agency selling within weeks, as our guide to starting an online travel agency explains. A custom engine pays off later, once search volume, the number of suppliers or a ranking idea outgrows what a rented platform allows. Then it gives you:

• Your own ranking: how price, fit, margin and conversion are weighed, and which offers lead.
• Your own supplier mix, including direct hotel contracts and a second bedbank, without waiting for a platform's roadmap.
• Control of the cost per search. The freshness policy and request coalescing decide how many searches reach a supplier, and so how close you run to quotas and look-to-book limits.
• Latency engineered for your traffic, with an in-memory tier sized for your peak.
• The search logs. What travelers looked for and did not find is input for pricing, contracting and recommendations.
• Searches a generic platform does not model: multi-city trips, ski-in hotels, accessible rooms, a B2B rate structure.

If the first column describes your business, start there. The rest of this guide is for when it no longer does.

Building a custom travel search engine: step-by-step process

The steps follow the order in which the decisions depend on each other: the suppliers set the data model, the data model sets the cache, and the cache policy sets how much the search tier has to compute in memory. Expect to revisit the first steps once the first supplier is live.

1. Set the requirements and choose the suppliers

Write the numbers down before any architecture: peak searches per second, the latency target at the 95th and 99th percentile, markets and currencies, products (hotels only, or flights and packages too), and the share of searches you can afford to send to suppliers. Name the query shapes as well. A dated search for one city, a flexible-date calendar and a map view load the system in different ways.

Then compare suppliers on coverage in your markets, integration style, contract limits and certification effort. Integration style shapes the architecture: besides its live availability API, Hotelbeds offers a Cache API that delivers a snapshot of its prices and availability as files, refreshed hourly, for partners that compute availability on their own side. For flights the choice is between a GDS, direct NDC connections and an aggregator. Our online travel agency guide describes these supply sources and how to get live access to each.

2. Design the data model

Separate three kinds of data, because each changes at a different speed and gets its own cache policy:

• Static content: properties, room types, amenities, photos, coordinates, airports and routes. Changes rarely.
• ARI (availability, rates and inventory): nightly rates per room type and rate plan, restrictions such as a minimum stay, and allotments. Changes many times a day.
• Offers: a priced, bookable combination returned for one query, with the supplier's token for booking it. Valid for minutes.

The offer is the record the rest of the system passes around. A minimal version in Java, with the cache key for a hotel price:

record Offer(
    String supplier,              // "hotelbeds", "expedia-rapid", ...
    String supplierRateKey,       // opaque: copy it, never parse it
    long propertyId,              // master property id after mapping
    LocalDate checkIn, int nights,
    Occupancy occupancy,          // adults, ages of children, rooms
    String roomName, String ratePlan, Board board,
    Money total,                  // what the traveler pays, in the shown currency
    Money taxesIncluded, Money payAtProperty,
    CancellationPolicy cancellation,
    boolean recheckBeforeBooking, // Hotelbeds: rateType RECHECK
    Instant fetchedAt, Instant expiresAt) {}

record HotelPriceKey(long propertyId, LocalDate checkIn, int nights,
                     Occupancy occupancy, String market, String currency) {}

Two rules in it come from supplier documentation. Treat the supplier's rate key as opaque: Hotelbeds tells partners not to parse the rateKey, because its format can change at any time. And keep the recheck flag. Hotelbeds marks each rate as BOOKABLE or RECHECK, and only RECHECK rates need a rate check before booking. The master property ID comes from the mapping built in the next step.

3. Integrate and certify each supplier

Put each supplier behind an adapter that turns the common search request into the supplier's calls and the response into your offer model. Everything supplier-specific stays inside it: authentication, splitting requests (2,000 hotels per Hotelbeds call, 250 properties per Expedia Rapid call), compression, retries and error codes.

Fan-out is where latency is lost.

Call suppliers in parallel with a timeout per supplier, return what has arrived when the search budget runs out, and isolate each adapter with its own connection pool and circuit breaker, so one slow supplier cannot hold up the others. Booking calls need different settings: Hotelbeds asks partners to set the booking confirmation timeout to at least 60 seconds, far beyond any search budget.

Property mapping belongs in this step as well. Match each new supplier property to a master record by the distance between coordinates, the normalized name and address, and any shared codes; merge confident matches automatically and send the rest to a review queue. A wrong match shows the traveler the wrong hotel, so tune the matcher to miss a merge rather than make a false one.

Bedbanks and OTA partner programs review the integration before they grant live access; Hotelbeds, for example, reviews the workflow, the calls per booking and the voucher. Plan for review rounds, and build the adapters so the second supplier does not wait for the first.

4. Write the caching and freshness policy

This step decides cost and accuracy, and its output should be a written table, owned by the business as much as by engineering. For each kind of data it states the maximum age when shown, what refreshes it and whether it is checked live:

The large engines work this way. Skyscanner's Indicative Prices API serves exploratory searches from prices that are cached and can be up to 4 days old, and a separate Live Prices API serves the dated search. Google's hotel feeds support both models. In Pull mode Google queries the partner and keeps the prices in its cache until its algorithms judge them stale, based on that partner's history of price changes. With ARI, pushed updates show within 15 to 20 minutes. And at auction time Google can send a Live Pricing Query for the price it is about to show.

Four techniques keep supplier traffic down without serving wrong prices:

• A TTL per supplier and destination, learned from how often prices actually changed there, instead of one global value.
• Invalidation by push. Where a supplier or a hotel sends ARI changes, update the cached entry on arrival and keep the TTL as a safety net.
• Request coalescing. When 500 travelers search the same city and dates within a second, one supplier call answers all of them.
• Pre-warming. Refresh the most searched destinations and dates in the background, so the first traveler in the morning does not wait for a cold cache.

Measure the result as price accuracy: the share of live checks that confirm the cached price. Track it per supplier and destination, and shorten the TTL where it drops. Low accuracy shows up as failed bookings and refunds, which our online travel agency guide covers from the agency's side.

5. Build the search and pricing engine

At high volume the search tier cannot query a relational database for each request. It has to hold the ARI it needs in memory, next to the code that turns nightly rates into a price for one query: summing the nights, applying length-of-stay rules, occupancy supplements and child policies, taxes, currency conversion and your markup.

An in-memory data grid fits this shape. It partitions the data across nodes by property or destination and runs the pricing function on the node that owns the data, instead of moving rates across the network. A loader fills the grid from the system of record at start-up, and a message stream applies changes during the day. Our overview of what Hazelcast is used for describes one such product.

We did this for a major UK hotel bookings aggregator. Its availability search ran as database processing on dozens of SQL Server machines, and the architecture had stopped scaling: adding a machine raised infrastructure cost by about 2 percent and throughput by about 0.1 percent. We moved availability search into an in-memory data grid that holds the complete data needed to answer a hotel availability query, with a custom fast loader from the database and a message queue pipeline for intraday updates. SQL Server stayed the system of record.

After the redesign the engine handled 300 million queries a day, 50 percent more traffic than before. Response time fell 60 percent, 95 percent of queries are answered in under a second, and infrastructure cost fell 80 percent. Adding nodes adds throughput at about 70 percent scaling efficiency, so growth became a capacity decision again. The case study has the details.

Keep the data in the grid compact and pre-computed: one entry per property and date range rather than one object per price, in a serialized form the pricing function can read without copying. Garbage collection pauses land directly in the 99th percentile, so the JVM advice in our guide to low-latency Java applications applies here.

6. Rank the results

Ranking runs after normalization and de-duplication, on one card per property or itinerary that holds its cheapest valid offer and the other offers behind it.

Start with hard filters (budget, star rating, board, refundable only, maximum stops), then a transparent score: the total price with taxes and mandatory fees, the fit to the query (distance from the point the traveler searched, room size for the party, flight duration), the review score, and the commercial term, which is the click price on a metasearch engine and the margin on an OTA. Label paid placements as sponsored.

Once a few months of click and booking logs exist, a learned model can replace the hand-set weights. Our guide to building a recommendation system covers the retrieval and ranking funnel such models run in.

Rank on the price the traveler will pay. Sorting by a base rate and adding fees on the booking page breaks Google's price accuracy policy and shows the traveler a higher price at checkout than in the list.

7. Test correctness, price accuracy and load

Test the price calculation against golden cases first: stays that cross a rate change, children's ages at the policy boundaries, taxes per night against taxes per stay, currency rounding. On the flight schedule calculation proof of concept we ran for a global flight information company, functional tests had to show the same daily output as production before any performance comparison counted. The new code then cut calculation time by 65 percent on identical input.

Supplier integrations get contract tests against each sandbox, plus recorded responses replayed in CI, so the suite does not use up sandbox quotas.

Load tests need production-shaped traffic: the real mix of destinations and dates, mostly reads, bursts when a campaign starts, and supplier mocks that add realistic latency, timeouts and errors. Gatling, k6 or JMeter generate the load; the traffic model is the hard part. Add a soak test of several hours, because cache growth and garbage collection problems take hours to appear.

Then test accuracy the way production will measure it: sample cached prices, check them live and compare the rate with the target in your freshness policy.

8. Deploy and monitor

Release adapter and ranking changes one at a time, behind feature flags and on a canary share of traffic, so a supplier problem can be switched off without a deployment. For the grid, plan rolling restarts, a backup copy of each partition and a loader that can rebuild a node from the system of record.

Monitor per stage and per supplier:

• latency at p50, p95 and p99 for the whole search and for each supplier call;
• cache hit ratio by type of data, and the share of searches forwarded to each supplier;
• price accuracy, and the rate of price-changed or sold-out answers at booking;
• supplier errors, timeouts and quota use against the contract limits;
• infrastructure cost per thousand searches.

Where to start a travel search engine project

Start with two documents: the volume and latency targets from step 1 and the freshness table from step 4. Together they show whether you need a custom engine at all, how much traffic will reach your suppliers and how large the in-memory tier must be.

We have built that tier for a hotel metasearch engine that answers 300 million queries a day. If you are planning a travel search engine, or running one that has stopped scaling, our travel software development team can go through your numbers on a scoping call and tell you in writing what we would build, or that a packaged platform would serve you better.