Provider Fallback Strategy

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.