Stale-While-Revalidate

Why it matters

Metasearch fan-out architectures need resilience because upstream latency and data volatility are unavoidable. Cache, timeout and retry decisions affect not only backend performance but also whether the displayed offer is trustworthy. These concepts should be designed with SLOs, freshness and failure isolation.

What does it look like in practice?

When one supplier's p95 latency rises, timeout, circuit breaker and fallback cache may work together. A successful stale fallback can still increase price-quality risk.

Implementation questions

• What is the end-to-end latency budget?
• Are cache age and source timestamps retained?
• Which error classes are retried?
• Can one provider failure degrade every supplier?

Common mistakes

• Retrying every error class
• Optimizing cache hit ratio without freshness
• Allowing one provider to block the entire fan-out

Where does it appear in the travel stack?

Stale-While-Revalidate commonly appears across resilience layers. Its implementation should make source-of-truth, identity, freshness and transaction-ownership boundaries explicit.

Related terms