Rarely do modern ASP.NET Core apps function independently. They interact with third-party APIs, databases, payment gateways, cloud storage, messaging services, and authentication providers. Although these dependencies are necessary, they also bring to uncontrollable failures for your program.
Your application shouldn't crash right away due to a brief network outage, a sluggish external API, or a throttled cloud service. Applications should instead minimize the impact on users, recover gracefully, and guard against cascade failures in downstream services.
Polly is the de facto resilience library for .NET, allowing
developers to implement retry, circuit breaker, timeout, fallback, and
other resilience patterns with minimal code changes. Combined with HttpClientFactory, Polly helps build reliable, production-ready applications.
In this article, you'll learn how to implement resilience policies in ASP.NET Core, understand when to use each strategy, and build a resilient communication pipeline for external services.
Why Resilience Matters
The Reality of Distributed Systems
Consider an order processing application.
If the payment gateway becomes temporarily unavailable:
Orders cannot be completed.
Customer requests fail.
Application reliability decreases.
Support requests increase.
Not every failure requires immediate failure. Many are temporary and recover automatically within seconds.
Understanding Retry
What Is Retry?
Retry automatically repeats an operation after a transient failure.
Typical transient failures include:
Temporary network interruptions
HTTP 503 responses
Connection resets
Cloud service throttling
Instead of failing immediately, the application retries the request after a short delay.
Configuring Retry
Register an HttpClient with a retry policy.
Why Use Retry?
Many failures are temporary.
Retrying a request a small number of times often succeeds without requiring user intervention.
However, retries should remain limited because excessive retries can increase load on already struggling services.
Understanding Circuit Breaker
Retries alone cannot solve every problem.
If a service remains unavailable, repeatedly retrying requests wastes resources.
Circuit Breaker addresses this issue.
Why Use a Circuit Breaker?
After several consecutive failures:
Requests stop reaching the failing service.
Resources are preserved.
Recovery time improves.
Cascading failures are reduced.
After the configured break period expires, the circuit allows limited traffic to determine whether the service has recovered.
Configuring Timeouts
Waiting indefinitely for an external service reduces application throughput.
Why Use Timeouts?
Timeouts prevent slow external services from consuming request threads indefinitely.
Combined with retries and circuit breakers, they help maintain predictable response times during dependency failures.
Implementing Fallback
Sometimes an alternative response is preferable to a failure.
Why Use Fallback?
Fallback provides a controlled response when every other resilience strategy fails.
Examples include:
Returning cached data
Displaying maintenance information
Serving default configuration
Returning partial results
Fallback should provide useful behavior rather than simply masking failures.
Combining Policies
Production applications rarely use a single resilience strategy.
Typical execution order:
Each policy addresses a different failure scenario.
Together they create a more reliable communication pipeline.
End-to-End Implementation
Consider an online retail platform.
Architecture:
Workflow:
A customer places an order.
The Order API calls the payment service.
If a transient failure occurs, Polly retries the request.
If repeated failures continue, the circuit breaker opens.
During the open state, requests fail immediately without contacting the external service.
If all recovery attempts fail, the fallback policy returns an alternative response.
Once the break interval expires, the circuit allows a limited number of requests to determine whether the external service has recovered.
This layered approach minimizes customer impact while preventing repeated failures from overwhelming dependent systems.
Comparing Resilience Strategies
| Strategy | Best For | Prevents |
|---|---|---|
| Retry | Temporary failures | Immediate request failures |
| Circuit Breaker | Repeated failures | Cascading failures |
| Timeout | Slow dependencies | Resource exhaustion |
| Fallback | Unrecoverable failures | Poor user experience |
Each strategy addresses a different reliability concern, and they are most effective when used together.
Best Practices
Retry only transient failures.
Use exponential backoff instead of immediate retries.
Configure realistic timeout values.
Keep circuit breaker thresholds conservative.
Use fallback responses only where appropriate.
Log resilience events for diagnostics.
Monitor retry and circuit breaker metrics.
Test resilience policies under failure conditions.
Combine Polly with
HttpClientFactoryfor centralized configuration.
Common Mistakes
One common mistake is retrying every exception indiscriminately. Permanent failures, such as authentication errors or invalid requests, should not be retried because they will continue to fail.
Another issue is configuring aggressive retry policies. Multiple retries across several services can amplify traffic and worsen outages rather than improving reliability.
Developers also sometimes treat fallback responses as a replacement for proper error handling. Fallback should provide an acceptable degraded experience, not conceal operational issues.
Testing and Validation
Before deploying resilience policies, verify:
Retry behavior
Circuit breaker activation
Timeout handling
Fallback responses
External API failures
Network interruptions
High-concurrency scenarios
Recovery after dependency restoration
Chaos testing and simulated dependency failures help validate resilience strategies under realistic production conditions.
Performance Considerations
Resilience policies improve reliability, but they should be configured carefully.
Consider these recommendations:
Limit retry attempts.
Use exponential backoff to reduce pressure on recovering services.
Monitor timeout frequency.
Avoid retrying long-running operations.
Track circuit breaker state changes.
Profile external dependency latency regularly.
Properly configured resilience policies improve overall system stability without introducing unnecessary processing overhead.
Security Considerations
Resilience mechanisms should not compromise application security.
Follow these recommendations:
Do not retry authentication failures caused by invalid credentials.
Log resilience events without exposing sensitive request data.
Protect API keys and secrets used by external services.
Validate HTTPS certificates for outbound requests.
Monitor repeated failures for signs of abuse or attacks.
Combine resilience with rate limiting and request timeouts.
Reliability and security should complement each other throughout the application's communication pipeline.
Troubleshooting
Retry Never Executes
Verify that the configured policy handles the specific exception or HTTP status code being returned by the external service.
Circuit Breaker Opens Too Frequently
Review failure thresholds and timeout settings. The configured limits may be too aggressive for normal traffic patterns.
Requests Continue Timing Out
Investigate the downstream service rather than continually increasing timeout values. Persistent timeouts often indicate an underlying performance issue.
Fallback Response Is Never Returned
Ensure the fallback policy wraps the retry, timeout, and circuit breaker policies in the intended execution order.
Conclusion
Building
resilient ASP.NET Core applications requires more than handling
exceptions. Retry policies recover from transient failures, circuit
breakers prevent cascading outages, timeouts protect server resources,
and fallback strategies provide graceful degradation when dependencies
remain unavailable. By combining Polly with HttpClientFactory
and carefully configuring resilience policies, developers can build
production-ready applications that remain responsive, reliable, and
easier to operate even when external services experience failures.
Windows Hosting Recommendation
