The engineering problem

A two-second search response in travel is not a user experience issue. It is a revenue issue. Each additional second of latency reduces conversion by measurable percentages, and in travel, where session abandonment is high and alternatives are one tab away, that cost compounds quickly. The problem becomes acute not at launch but at scale: platforms that perform adequately at 100,000 listings begin showing strain at one million, and the architecture decisions that felt acceptable early become the constraints that define the ceiling.

Two failure modes appear together. Availability responses that are stale by the time they reach the user, showing inventory that booked out 30 seconds ago. Faceted filters counting against the full catalog rather than genuinely available results, leading buyers into dead ends. Neither is a data quality problem. Both are architecture problems.

Search architecture

The backbone of production-grade travel search is a dedicated search engine, not a relational database with added indexes. Elasticsearch and OpenSearch are the standard choices, and the selection matters less than the index design built on top of them. For travel inventory, a well-designed index encodes multi-attribute documents covering location, date ranges, capacity, pricing tiers, amenity sets, ratings, and availability windows in a structure that supports the platform’s specific query patterns. The difference between a good index design and a mediocre one becomes visible at one million listings and critical at fifteen. Field selection, analyzer configuration, and shard strategy determine whether sub-500ms P99 latency is achievable under peak load.

Property deduplication and record matching

One of the most underestimated engineering problems in travel search is deduplication: the same hotel, villa, or property appearing in search results multiple times because it comes from different suppliers with different identifiers, different names, and different data models.

A single property can appear in a platform’s inventory from an OTA channel manager, a direct hotel API, a GDS feed, and a bed bank - each carrying a different property ID, a slightly different address, and a name that may or may not match exactly. Without a deduplication layer, users see the same property listed four times at four prices, with no indication they are looking at the same room. Conversion drops. Supplier trust drops. The platform looks unreliable.

The standard industry reference for solving this is GIATA - a German company that maintains a master property database covering more than 750,000 hotel properties worldwide, each assigned a unique GIATA ID that persists across distribution channels. Mapping incoming supplier inventory to GIATA IDs allows a platform to resolve the same property across different feeds into a single canonical record, then display multiple supplier prices against that record rather than showing duplicates. Gradion builds the GIATA integration and the deduplication pipeline that normalises incoming inventory into a clean property graph: canonical record creation, attribute merging from multiple sources, conflict resolution when suppliers disagree on room counts or amenity data, and downstream index update propagation when the master record changes.

For platforms that cannot use GIATA - either due to licensing cost or because the inventory type (rental properties, private villas, activity venues) is not well-covered by the database - Gradion builds probabilistic matching pipelines that cluster duplicate candidates using name similarity, geocoordinate proximity, and attribute overlap, with a confidence scoring layer and a manual review queue for low-confidence matches. The engineering challenge is recall: missing a duplicate is worse than a false positive in most cases, because users will find it and trust the platform less.

Real-time availability

Inventory state in travel changes continuously. Bookings happen concurrently, hold periods expire, partner feeds update asynchronously. The architecture question is not whether to reflect real-time state but how to do so without making every search query a synchronous call into a slow external system.

The practical answer for large platforms is a hybrid: the search layer works from a maintained availability index, updated through event streams on booking, cancellation, and hold expiry, while the checkout path performs a live confirmation check before committing a reservation. HomeToGo coordinates availability across 100+ partner APIs and 15M+ listings across 25 markets. The engineering challenge is synchronising state from heterogeneous sources - each with different update frequencies, data formats, and reliability characteristics - into a consistent internal model that search queries can trust. The integration layer that normalises this data is as much of the engineering effort as the search engine itself.

Caching strategy

Not everything in a travel search response has the same volatility. Static attributes, amenity lists, location data, and historical pricing patterns can be cached with reasonable TTLs. Real-time availability cannot. Getting this boundary wrong creates problems in both directions: overly aggressive caching shows unavailable inventory and destroys trust; under-caching degrades search latency. Cache invalidation on booking events is required for any inventory that is held or confirmed. The design of what lives in cache, at what TTL, and what triggers invalidation is not a detail - it is a correctness constraint.

Faceted search and filtering

Faceted filters that accurately reflect available inventory at query time require aggregation across the filtered result set, not the full catalog, to produce counts that correspond to what users can actually book. Achieving this without full-table scans requires careful use of search engine aggregation capabilities and, where count precision is less critical than speed, approximate techniques. Dynamic facets - where value ranges and counts update as filters are applied - place additional demands on query construction and latency. Specialist filtering requirements demand additional investment in the content layer: a Muslim-focused travel platform requires halal certification, prayer facility, and alcohol policy as filterable attributes, which means those attributes must be consistently present and verified in the inventory before they can be surfaced as reliable filter options. Gradion has built the content enrichment pipelines that make specialist filtering credible, not just technically present.

Relevance ranking and GDS integration

Keyword relevance is the floor, not the ceiling, of travel search ranking. Multi-signal ranking incorporates price competitiveness, availability confidence, historical conversion rates by property and market segment, and geographic proximity to stated intent. Machine learning re-ranking trained on booking conversion data adds a personalisation layer that improves with scale. For platforms sourcing inventory from global distribution systems, the availability pipeline connects to Amadeus, Sabre, or Travelport feeds alongside direct channel manager APIs. Each source carries its own data model, update cadence, and reliability profile. Normalisation into a consistent internal availability model is a prerequisite for coherent search results, and the mapping layer is where many integrations accumulate correctness problems over time as source schemas evolve.

Geospatial search

Location is a primary search axis in most travel categories. OpenSearch and Elasticsearch provide native geospatial query support covering bounding box queries for map-view search, radius queries for proximity filtering, and polygon queries for destination-area search. For accommodation and activity platforms, combining geospatial filtering with availability and attribute filters in a single query is the standard requirement and, handled correctly, adds minimal overhead to query latency.

Proof in production

KAYAK is the world’s largest travel search platform, processing over 2 billion consumer queries annually across 60 markets. NFQ (represented by Gradion) built and ran a high-performance engineering team embedded in KAYAK’s product development over more than a decade. The work covered the core search and availability infrastructure that operates at the scale KAYAK runs at: multi-supplier aggregation, real-time availability normalisation across heterogeneous feed sources, relevance ranking at billions of queries per year, and the latency engineering that flight and accommodation metasearch requires. In 2018, KAYAK acqui-hired approximately 40 of those engineers directly into KAYAK Lithuania - the clearest possible signal that the team had been operating at internal engineering standards, not external contractor ones.

HomeToGo is the world’s largest vacation rental marketplace, with 15M+ listings, 60,000+ trusted partners, and operations across 25 countries. NFQ (represented by Gradion) provided engineering teams of up to 150 engineers across four offices: 50+ production deployments per day, 100+ concurrent A/B tests, and 99.99% uptime across a system integrating 100+ partner APIs into a unified availability model. The deduplication and normalisation challenges of aggregating 15 million listings from heterogeneous sources are a direct reference for what property matching at scale requires.

roadsurfer: full platform rebuild in 20 days, 8 languages, 7 currencies. Bookings and revenue doubled within a year of launch.

CTA

Describe the inventory size, query patterns, and current performance constraints. We will scope the search architecture.