Skip to main content

Fallback Strategy

The fallback reactive resilience strategy provides a substitute if the execution of the callback fails. Failure can be either an Exception or a result object indicating unsuccessful processing.
Typically, fallback is used as a last resort - if all other strategies failed to overcome the transient failure, you can still provide a fallback value to the caller.

When to Use Fallback

Use the fallback strategy when:
  • You can provide a sensible default value when operations fail
  • Cached data can be used instead of fresh data
  • Degraded functionality is acceptable over complete failure
  • You want to call an alternative service or endpoint
  • Graceful degradation is more important than complete accuracy

Installation

Usage

Basic Fallback with Constant Value

Dynamic Fallback Value

Fallback with Cached Data

Fallback with OnFallback Event

Fallback to Alternative Service

Configuration Options

Predicate
Defines which results and/or exceptions should trigger the fallback.
Func<FallbackActionArguments, Outcome<TResult>>
required
Delegate that calculates the substitute value. Can access the outcome and context to make decisions.
Func<OnFallbackArguments, ValueTask>
default:"null"
Invoked before the strategy returns the fallback value. Useful for logging and metrics.

Best Practices

Place fallback outside other strategies so it catches all failures:
Don’t return generic defaults. Consider the context:
Stale data is often better than no data. Implement cache-aside pattern with fallback.
Always log when fallback is used to track system health:
If fallback is frequently triggered, it might indicate a persistent problem. Monitor fallback rates and alert on trends.

Common Patterns

Fallback After Retries

Primary-Secondary Endpoint Pattern

Fallback with Quality Indicators

Examples

User Profile with Fallback

Configuration Service with Fallback

Multi-Region Fallback

  • Retry: When you want to attempt the same operation again, hoping it will succeed
  • Fallback: When you want to provide an alternative value or call a different operation
Often used together: Retry first, then fallback if all retries fail.
No, the fallback must return the same type as the original operation. However, you can use wrapper types that indicate whether the result is primary or fallback data.
No. Only use fallback when:
  • You have a sensible default or cached value
  • Degraded functionality is acceptable
  • You can call an alternative service
Some failures should propagate to the caller.
Options:
  1. Return a wrapper type with a flag (e.g., DataResult<T> with IsFallback property)
  2. Set a value in ResilienceContext.Properties
  3. Use OnFallback to log or emit metrics