Fallback Strategy
The fallback reactive resilience strategy provides a substitute if the execution of the callback fails. Failure can be either anException or a result object indicating unsuccessful processing.
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
Use fallback as the outermost strategy
Use fallback as the outermost strategy
Place fallback outside other strategies so it catches all failures:
Provide contextually appropriate fallbacks
Provide contextually appropriate fallbacks
Don’t return generic defaults. Consider the context:
Consider using cached data
Consider using cached data
Stale data is often better than no data. Implement cache-aside pattern with fallback.
Log fallback occurrences
Log fallback occurrences
Always log when fallback is used to track system health:
Don't hide persistent failures
Don't hide persistent failures
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
When should I use Fallback vs Retry?
When should I use Fallback vs Retry?
- 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
Can fallback return a different type?
Can fallback return a different type?
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.
Should I always provide a fallback?
Should I always provide a fallback?
No. Only use fallback when:
- You have a sensible default or cached value
- Degraded functionality is acceptable
- You can call an alternative service
How do I indicate that fallback data was used?
How do I indicate that fallback data was used?
Options:
- Return a wrapper type with a flag (e.g.,
DataResult<T>withIsFallbackproperty) - Set a value in
ResilienceContext.Properties - Use
OnFallbackto log or emit metrics