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:

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:

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

Common Mistakes

Retrying Every Failure

Not every failure should be retried.

For example:

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.