Flight search is the slowest and most expensive step on any booking website. Every search can call a GDS or an airline API, wait several seconds for a response, and count against your look-to-book limits. Caching solves much of this, but flight prices change constantly, so a careless cache shows travellers fares that no longer exist. This guide explains how to cache flight results so search stays fast and prices stay honest.
Why flight search needs caching
A single search for a popular route can return hundreds of itineraries from several suppliers. Calling every supplier live for every search causes three problems:
- Slow results. Travellers leave if results take too long to appear, especially on mobile.
- High supplier costs. Many suppliers charge for searches or set a maximum ratio of searches to bookings (the look-to-book ratio).
- Rate limits. Traffic spikes from marketing campaigns can hit supplier limits and cause failed searches.
A cache stores recent search responses so repeated searches for the same route and date can be answered in milliseconds.
What to cache, and what never to cache
Not every part of a flight response can be reused. A safe rule is to cache what helps the traveller browse, and always re-check what they pay.
- Safe to cache: search results for a route, date and passenger mix; airline names, logos and airport data; fare family descriptions and baggage text.
- Cache briefly: lowest fares for calendar and "cheapest day" views, which can be refreshed in the background.
- Never cache: the final price check before payment, seat availability during seat selection, and booking or ticketing responses.
Choosing the right cache lifetime
There is no single correct time-to-live. It depends on how quickly fares move on each route:
- Departures within the next few days change fastest, so keep cache times very short or skip the cache.
- Departures months away change more slowly and can be cached longer.
- Busy routes and holiday periods need shorter cache times than quiet routes.
Many teams start with conservative values, measure how often the price changes between search and booking, and then tune the lifetime route by route.
Always re-price before payment
The most important rule: whatever the cache shows, the booking flow must re-check the fare with the supplier before taking payment. This step is often called "revalidation" or "fare confirmation". If the price has changed, show the traveller the new price clearly and let them accept it or go back. Hiding a price change until after payment leads to failed tickets, refunds and complaints.
Keeping the cache fresh in the background
Instead of waiting for a traveller to trigger a slow search, a portal can refresh popular searches in the background:
- Pre-load the top routes and dates from your own search history.
- Refresh calendar fares at off-peak hours.
- Expire cache entries immediately when a booking attempt reveals a price change.
Background refreshing must respect supplier rules. Some suppliers do not allow automated searches, so check your agreement first.
Measuring whether caching works
Track a few numbers after you switch caching on:
- Cache hit rate: the share of searches answered from cache.
- Price-change rate at revalidation: how often the confirmed fare differs from the displayed fare. If this rises, shorten cache times.
- Search response time on desktop and mobile.
- Look-to-book ratio per supplier, to make sure you stay within agreed limits.
Common caching mistakes
- One cache time for every route. A single global lifetime is either too long for busy routes or too short for quiet ones. Tune by route and departure window.
- Caching per user instead of per search. The cache key should describe the search (origin, destination, dates, passengers, cabin), not the visitor, so every traveller benefits.
- Forgetting the passenger mix. A fare for one adult is not the fare for two adults and a child. Include passenger types in the cache key.
- Ignoring supplier terms. Some agreements limit how long you may store or display fares. Read them before designing the cache.
Frequently asked questions
Does caching reduce booking failures?
Caching itself does not, but combining caching with revalidation does. The traveller sees fast results, and the revalidation step catches price changes before payment instead of after.
Where should the cache live?
Most booking engines use an in-memory store such as Redis for search results because it is fast and supports automatic expiry. Static reference data, such as airports and airlines, can be stored in the main database.
Can I cache NDC and low-cost carrier fares?
Yes, with care. These fares often change quickly and may include dynamic pricing, so short cache times and strict revalidation are especially important.
Key takeaways
- Cache search results to make flight search fast and reduce supplier costs.
- Never cache the final price check, seat availability or booking responses.
- Set cache lifetimes by how close the departure is and how busy the route is.
- Always revalidate the fare before payment and show any price change clearly.
Planning a flight booking engine with multiple suppliers? Our team builds caching, revalidation and supplier fallback into every flight API integration project.
