Caching flight search without selling prices you cannot honour

Caching in flight search means storing supplier responses so repeat searches can be answered without calling the airline or GDS again. It reduces cost and latency dramatically, but airline prices change constantly, and a cache that is too aggressive shows fares that disappear at checkout. The goal is not maximum hit rate; it is the best trade-off between speed, supplier cost and price accuracy.

Why caching is unavoidable

Flight search is expensive. Each search fans out to several suppliers, each response is large, and many suppliers charge or limit traffic relative to bookings — the look-to-book problem. Without caching, a platform with growing traffic pays for every browse and every price comparison.

Why caching is dangerous

Fares depend on availability buckets that open and close in real time. With NDC, offers are generated dynamically and carry explicit expiry times. A cached price is therefore a prediction, not a quote. When predictions are wrong, customers see a higher price at checkout, conversion falls and trust erodes.

Design the cache key carefully

The key decides which searches can share a result. Typical components:

• origin, destination and dates,
• passenger types and counts,
• cabin and key search options,
• point of sale, currency and customer segment where prices differ.

Leave out something that affects price and you will serve wrong results. Include too much and the hit rate collapses. Start strict and loosen only with evidence.

Use variable TTLs, not one number

Volatility is not uniform. Reasonable starting rules:

• Near-term departures — short lifetimes; prices move fastest close to travel.
• High-demand routes — short lifetimes; inventory turns over quickly.
• Distant, low-demand dates — longer lifetimes are usually safe.
• Dynamic offers with expiry — never cache beyond the supplier’s expiry.

Then measure and adjust, rather than debating the numbers.

Layer the cache

Different data has different volatility, so cache it separately:

1. Static content — airports, airlines, aircraft, fare brand descriptions. Cache for days.
2. Schedules — which flights exist. Cache for hours.
3. Prices and availability — cache for minutes, segmented as above.
4. Selected offer — never served from cache at checkout; always re-priced.

A Redis cluster handles this well, with per-layer key prefixes and TTLs. Patterns for that are in Redis beyond caching.

Pre-warming and stale-while-revalidate

For the routes that drive most traffic, refresh cached results in the background before they expire, within supplier limits. For less critical routes, serve a slightly stale result immediately and refresh it asynchronously so the next user sees a fresh one. Both techniques keep latency low without making every user wait for suppliers.

Re-price before payment, always

Whatever the cache does, checkout must re-price the selected offer with the supplier. Treat a changed price as a normal outcome: show the new price, explain briefly, and let the customer continue. The full flow is described in anatomy of a travel booking engine.

Measure accuracy, not just hit rate

Three metrics make caching decisions objective:

• Hit rate — how often search avoided a supplier call.
• Price-change rate at re-price — how often the confirmed price differed from the displayed one.
• Price-change magnitude — how large the differences were.

Segment them by route, supplier and days to departure. A high hit rate with a rising price-change rate means the cache is costing you bookings.

The takeaway

Cache aggressively where prices are stable, conservatively where they are not, and never at checkout. Measuring the price-change rate turns caching from guesswork into an engineering decision that balances cost against conversion.