resilience

Fallback Strategy

Chain alternative providers — gracefully degrade through progressively simpler responses

StatusIDLE
Elapsed0.0s
Runs0
Resolved0
All Failed0
Fallback Chain
●
Primary Service
~400ms latency · 60% failure rate
standby
◆
Secondary Service
~600ms latency · 30% failure rate
standby
◎
Local Cache
~50ms latency · 5% failure rate
standby
□
Static Default
~5ms latency · 0% failure rate
standby

// fallback chain configuration

● Primary Service
◆ Secondary Service
◎ Local Cache
□ Static Default
PRESETS:

// event log

No events yet. Click "Execute Request" to begin.

// how it works

  • Define a chain of fallback strategies in priority order.
  • Try the primary service first.
  • If it fails, try the secondary service.
  • If that fails, try a local cache for stale data.
  • Last resort: return a static default value.
  • Each level degrades gracefully — the user always gets something.

// trade-offs

  • Users always get a response, even during outages
  • Graceful degradation instead of hard failure
  • Flexible — add/remove strategies per use case
  • Stale data from cache may confuse users
  • Default values may not be meaningful for all endpoints
  • Adds latency on failure (serial fallback chain)
  • Complexity grows with more fallback levels

// real-world usage

  • Netflix: fallback to cached recommendations when personalization fails
  • E-commerce: show cached product data when catalog service is down
  • CDN: origin → edge cache → stale-while-revalidate
  • API Gateway: primary → secondary region → static maintenance page
  • Composition: circuit-breaker → fallback → cache