Resiliência em .NET: Indo Além do Retries com Polly

Em sistemas distribuídos, a pergunta não é “se” vai falhar, mas “quando”. Uma API externa fora do ar não pode derrubar seu sistema inteiro.

O Polly é a biblioteca padrão para resiliência em .NET. Mas muitos devs param no Retry. Vamos ver padrões mais avançados.

1. Circuit Breaker: Pare de Bater em Quem Já Morreu

Se um serviço externo está fora do ar (retornando 503), ficar tentando a cada segundo só piora a situação (efeito manada) e trava suas threads.

O Circuit Breaker “abre o circuito” após X falhas, falhando imediatamente sem tentar chamar o serviço externo por um tempo. Isso dá tempo para o serviço se recuperar.

// Exemplo conceitual
pipeline.AddCircuitBreaker(new CircuitBreakerStrategyOptions
{
    FailureRatio = 0.5, // Abriu se 50% falhar
    SamplingDuration = TimeSpan.FromSeconds(10),
    MinimumThroughput = 20,
    BreakDuration = TimeSpan.FromSeconds(30) // Espera 30s antes de tentar de novo
});

2. Fallback: Tenha um Plano B

Se o serviço de recomendação falhar, não mostre um erro 500. Mostre uma lista de produtos “Mais Vendidos” que está em cache. Isso é Fallback. Degradação graciosa da experiência.

3. Hedging: Aposta Dupla

Esse é para baixa latência. O Hedging faz uma requisição. Se ela demorar muito (mas não falhar), ele lança uma segunda requisição simultânea. A que voltar primeiro ganha. Útil quando você tem réplicas de leitura e uma pode estar lenta.

4. Rate Limiter: Proteja-se

Não deixe um cliente abusivo derrubar sua API. Use o Rate Limiter (agora nativo no .NET 7+, mas o Polly também tem) para limitar requisições por IP ou usuário.

A Nova Era: Polly v8

O Polly v8 foi reescrito para ser “zero allocation” e muito mais performático. A sintaxe mudou (Resilience Pipelines), ficando mais limpa e integrada com a injeção de dependência do .NET.

services.AddResiliencePipeline("default", builder =>
{
    builder
        .AddRetry(new RetryStrategyOptions { MaxRetryAttempts = 3 })
        .AddTimeout(TimeSpan.FromSeconds(2));
});