---
title: "Provider Fallback Strategy"
description: "Design provider fallback for travel search and booking across outages, timeouts, stale cache and alternate suppliers."
slug: "provider-fallback-strategy"
translationKey: "architecture-provider-fallback-strategy"
locale: "en"
type: "guide"
category: "architecture"
tags: ["fallback","provider","resilience","search","booking"]
publishedAt: "2026-09-26"
updatedAt: "2026-09-26"
reviewedAt: "2026-09-26"
---

A fallback strategy should not blindly switch providers after every error. It should **define which degraded modes are acceptable for each failure and traveler intent level**.

## Production scenario

The primary supplier times out. A secondary provider has the same hotel but may be more expensive, while cache contains a 20-minute-old indicative offer.

## Fallback layers

A read/search flow can consider safe retry, cached result, alternate provider, stale/indicative result and finally partial/no result.

Booking-create flows require separate rules because switching providers can change the product and commercial terms.

## Eligibility

Alternate suppliers should be filtered by market coverage, property mapping, health, price quality, quota and commercial contract.

## Search versus booking

Fallback can be aggressive in read paths. In booking, changing provider can mean a different price or policy and may require explicit traveler confirmation.

## Failure modes

Common mistakes include failing over to providers sharing the same outage, showing stale cache as live, ignoring cancellation-policy differences, amplifying traffic through retry plus fallback and hiding commercial preference as technical fallback.

## Circuit breakers

Open-circuit providers should be removed from eligibility until controlled recovery.

## Observability

Track fallback rate, success, stale usage, alternate-provider conversion, price delta, added latency and amplification factor.

## Trade-offs

More fallback improves coverage but can reduce determinism and increase cost. Sometimes an explicit unavailable state is the better product decision.

## Production checklist

Define fallback classes, separate search from booking, use health-aware eligibility, cap fallback depth, label stale data, revalidate price/policy, guard against amplification and require confirmation for transaction changes.
