Designing Resilient ASP.NET Core APIs Using .NET 8 Resilience Pipelines

Introduction

For years, Polly was the go-to library for building resilient .NET applications. Retry policies, circuit breakers, timeouts—everything lived in Polly.

Starting with .NET 8, Microsoft introduced built-in Resilience Pipelines, marking a major shift in how fault tolerance is implemented in ASP.NET Core.

This article explores:

What resilience pipelines are
How they differ from Polly
How to build retry, timeout, and circuit breaker pipelines
Real-world API examples
Best practices for production systems

Why Resilience Matters in Distributed Systems

In modern systems:

APIs depend on external services
Networks fail
Latency spikes
Downstream services become unstable

Without resilience:

One failure cascades
Threads block
APIs crash under load

Resilience pipelines solve this inside the framework, not via third-party middleware.

What Are Resilience Pipelines?

A Resilience Pipeline is a composable execution flow that applies fault-handling strategies such as:

Retry
Timeout
Circuit Breaker
Hedging
Rate Limiting

They are:

Built on System.Threading.RateLimiting
Fully async
Dependency-injection friendly
Designed for cloud-native workloads

Adding Resilience Support

Required Package

dotnet add package Microsoft.Extensions.Resilience

Configuring a Resilience Pipeline

Step 1: Register Pipelines in `Program.cs`

using Microsoft.Extensions.Resilience;
using Polly.Timeout;

var builder = WebApplication.CreateBuilder(args);

builder.Services.AddResiliencePipeline("external-api", pipeline =>
{
    pipeline
        .AddTimeout(TimeSpan.FromSeconds(3))
        .AddRetry(new RetryStrategyOptions
        {
            MaxRetryAttempts = 3,
            Delay = TimeSpan.FromMilliseconds(500),
            BackoffType = DelayBackoffType.Exponential
        })
        .AddCircuitBreaker(new CircuitBreakerStrategyOptions
        {
            FailureRatio = 0.5,
            SamplingDuration = TimeSpan.FromSeconds(30),
            MinimumThroughput = 10,
            BreakDuration = TimeSpan.FromSeconds(15)
        });
});

builder.Services.AddHttpClient<WeatherClient>()
    .AddResilienceHandler("external-api");

var app = builder.Build();
app.MapControllers();
app.Run();

What’s Happening Here?

Strategy	Purpose
Timeout	Prevents thread starvation
Retry	Handles transient failures
Circuit Breaker	Stops cascading failures

Unlike Polly, this pipeline is

Centralized
Declarative
Observable

Using Resilience in a Typed HTTP Client

Step 2: Create a Typed Client

public class WeatherClient
{
    private readonly HttpClient _httpClient;

    public WeatherClient(HttpClient httpClient)
    {
        _httpClient = httpClient;
    }

    public async Task<string> GetWeatherAsync()
    {
        var response = await _httpClient.GetAsync("https://external-api/weather");
        response.EnsureSuccessStatusCode();

        return await response.Content.ReadAsStringAsync();
    }
}

Failures here will automatically:

Retry
Timeout
Open circuit when unhealthy

Exposing the API Endpoint

[ApiController]
[Route("api/weather")]
public class WeatherController : ControllerBase
{
    private readonly WeatherClient _client;

    public WeatherController(WeatherClient client)
    {
        _client = client;
    }

    [HttpGet]
    public async Task<IActionResult> Get()
    {
        var result = await _client.GetWeatherAsync();
        return Ok(result);
    }
}

Advanced: Using Hedging for Faster Responses

Hedging sends multiple parallel requests and uses the fastest response.

pipeline.AddHedging(new HedgingStrategyOptions
{
    MaxHedgedAttempts = 2,
    Delay = TimeSpan.FromMilliseconds(200)
});

This is ideal for:

High-latency APIs
Read-heavy services
Geo-distributed systems

Observability and Metrics

Resilience pipelines integrate with:

OpenTelemetry
ILogger
Metrics providers

Example:

builder.Services.AddOpenTelemetry()
    .WithMetrics(metrics =>
    {
        metrics.AddAspNetCoreInstrumentation();
        metrics.AddHttpClientInstrumentation();
    });

You get visibility into:

Retry counts
Circuit breaker states
Timeout failures

When to Use Resilience Pipelines vs Polly?

Scenario	Recommendation
New .NET 8+ apps	Resilience Pipelines
Legacy systems	Polly
Deep customization	Polly
Cloud-native APIs	Resilience Pipelines

Production Best Practices

✔ Avoid retries on non-idempotent requests
✔ Keep timeouts short
✔ Monitor circuit breaker states
✔ Combine with rate limiting
✔ Test failure scenarios locally

Why This Matters for .NET Developers

Resilience Pipelines represent:

Microsoft’s future direction
A move away from external dependencies
A standardized approach to fault tolerance

Ignoring this feature means missing one of the most important architectural improvements in modern .NET.

Conclusion

With .NET 8, resilience is no longer an afterthought or a third-party concern. Resilience pipelines offer a powerful, built-in, and production-ready way to build fault-tolerant ASP.NET Core applications.

If you’re building APIs for real-world traffic, this feature is no longer optional—it’s essential.