Modern applications rarely operate in isolation. A typical ASP.NET Core API communicates with databases, third-party APIs, message brokers, payment gateways, and cloud services. While these dependencies are essential, they can also become points of failure due to network issues, service outages, or temporary overload.
Without proper resilience mechanisms, a single failing dependency can slow down or even bring down an entire application. Polly v8 is a resilience library for .NET that helps developers handle transient failures gracefully using strategies such as retries, timeouts, circuit breakers, and fallbacks.
In this article, you'll learn how Polly v8 works, how it differs from earlier versions, and how to implement resilient HTTP communication in ASP.NET Core applications.
Why API Resilience Matters
Imagine an API that retrieves customer data from an external service.
Client
│
ASP.NET Core API
│
External Customer API
If the external service experiences temporary failures, every request to your API may also fail.
Common causes include:
Instead of immediately returning errors, resilient applications attempt to recover from temporary failures while protecting downstream services.
What's New in Polly v8?
Polly v8 introduces a new resilience pipeline model that replaces the older policy-based API.
Instead of combining multiple policies manually, developers now configure a Resilience Pipeline containing one or more resilience strategies.
Benefits include:
This modern approach aligns well with current .NET development practices.
Configuring Polly v8
Install the required package:
dotnet add package Microsoft.Extensions.Http.Resilience
Configure an HTTP client with resilience support.
builder.Services.AddHttpClient("ProductsApi")
.AddStandardResilienceHandler();
This single configuration adds a recommended set of resilience strategies, including retries, timeouts, circuit breakers, and rate limiting.
For many applications, this provides a solid production-ready starting point.
Retry Strategy
Transient failures often resolve themselves after a short delay.
Instead of failing immediately, Polly retries the request automatically.
Example:
builder.Services.AddHttpClient("OrdersApi")
.AddStandardResilienceHandler(options =>
{
options.Retry.MaxRetryAttempts = 3;
});
Retries are useful for temporary issues such as:
However, excessive retries can increase load on already struggling services, so retry counts should remain conservative.
Timeout Strategy
A slow dependency can consume application resources and degrade performance.
Timeouts prevent requests from waiting indefinitely.
builder.Services.AddHttpClient("InventoryApi")
.AddStandardResilienceHandler(options =>
{
options.TotalRequestTimeout.Timeout =
TimeSpan.FromSeconds(10);
});
When the timeout is reached, the request is canceled, allowing the application to recover more quickly.
Circuit Breaker
If a downstream service continues to fail, repeatedly sending requests only wastes resources.
A circuit breaker temporarily stops requests after repeated failures.
The flow looks like this:
Request
│
Failure
│
Failure
│
Failure
│
Circuit Opens
│
Requests Fail Fast
After a recovery period, Polly allows limited requests to determine whether the service has recovered.
Circuit breakers help:
Protect downstream services
Reduce unnecessary retries
Improve overall system stability
Rate Limiting
Sending too many requests simultaneously can overload external services.
Polly v8 includes built-in rate limiting to control outbound traffic.
This is especially useful when calling APIs that enforce request quotas or usage limits.
Rather than overwhelming a dependency, requests are processed at a controlled rate.
Fallback Strategy
Sometimes returning an alternative response is better than returning an error.
For example:
Return cached product data
Display default configuration
Use placeholder content
Skip optional functionality
Fallbacks help maintain application availability even when some dependencies are unavailable.
They should be used carefully to avoid masking critical failures.
Combining Resilience Strategies
One of Polly v8's strengths is the ability to combine multiple strategies into a single resilience pipeline.
A typical request may follow this sequence:
HTTP Request
│
Retry
│
Timeout
│
Circuit Breaker
│
Fallback
│
Response
Each strategy addresses a different type of failure, resulting in a more resilient application.
Best Practices
Use the standard resilience handler unless custom behavior is required.
Retry only transient failures.
Keep retry attempts low to avoid unnecessary load.
Configure realistic timeout values based on service expectations.
Use circuit breakers to protect unstable dependencies.
Log resilience events for monitoring and diagnostics.
Test resilience behavior under simulated failure conditions.
Common Mistakes
Retrying Every Failure
Not every failure should be retried.
For example:
HTTP 400 Bad Request
Authentication failures
Invalid input
These errors typically require application changes rather than another request.
Using Very Long Timeouts
Long timeout values can tie up application threads and delay responses.
Choose timeout values that reflect expected service behavior.
Ignoring Monitoring
Resilience strategies improve reliability, but they should also be monitored.
Track:
These metrics help identify unstable dependencies before they become larger problems.
Assuming Polly Replaces Good Design
Polly improves resilience but cannot compensate for poor architecture.
Applications should still implement:
Resilience libraries complement these practices—they do not replace them.
Conclusion
Building resilient APIs is essential for modern distributed applications where failures are inevitable. Polly v8 provides a streamlined and powerful approach to handling transient faults through retries, timeouts, circuit breakers, rate limiting, and fallback strategies.
Its new resilience pipeline simplifies configuration while integrating seamlessly with ASP.NET Core and HttpClientFactory. By applying these strategies thoughtfully, developers can reduce the impact of temporary failures, protect downstream services, and improve overall application reliability.
Rather than treating resilience as an afterthought, incorporate it into your application's design from the beginning. Combined with effective monitoring, logging, and sound architectural practices, Polly v8 helps build .NET APIs that remain stable and responsive even when external dependencies experience failures.
Join the conversation! Your thoughts help the community grow.