Chaos Engineering para C#: quebrando aplicações para salvar o negócio

Introdução: Por que seu serviço C# não é um mecanismo ideal

Imagine: você escreveu um microsserviço elegante em C#. O código passou pelo code review, os testes unitários cobrem 95%, os testes de integração estão verdes. Você o implanta em produção e… após 3 horas o sistema cai. O motivo? Um pico inesperado de tráfego que sobrecarregou o pool de threads, ou uma desconexão repentina do banco de dados que você não previu.

Bem-vindo ao mundo real, onde o Chaos Engineering (engenharia do caos) se torna não um luxo, mas uma necessidade. Não se trata de "quebrar tudo por diversão". É uma disciplina que ajuda a identificar pontos fracos em sistemas distribuídos antes que seus usuários os descubram.

Neste artigo, vamos abordar como aplicar Chaos Engineering para aplicações C#: da teoria a exemplos reais de código usando as bibliotecas Polly e Simmy. Você aprenderá como introduzir caos intencionalmente em serviços .NET para aumentar sua resiliência e previsibilidade.

O que é Chaos Engineering e por que é importante para .NET?

Chaos Engineering é a prática de realizar experimentos em um sistema distribuído para testar sua capacidade de suportar falhas inesperadas. Netflix, Amazon, Microsoft — todos os gigantes usam isso. Para desenvolvedores C#, isso é especialmente relevante, pois o .NET Core/5+ é cada vez mais usado para construir serviços de alta carga e baseados em nuvem no Microsoft Azure.

Princípios básicos da engenharia do caos:

\n
• Definição do "steady state" (estado estável) — como seu sistema se comporta em condições normais (latência, throughput, taxa de erro).
\n
• Formulação de hipótese — "Se o banco de dados OrderDB cair, o serviço de pedidos continuará respondendo com dados em cache por 5 minutos".
\n
• Introdução do caos — você realmente desliga o OrderDB por 30 segundos.
\n
• Verificação da hipótese — observamos as métricas. Se a hipótese não for confirmada — você tem um bug na arquitetura.
\n

A palavra-chave aqui é "experimento". Você não está apenas torcendo para o melhor, você está provando que seu sistema sobreviverá.

Ferramentas para Chaos Engineering em C#

No mundo .NET, existem duas ferramentas poderosas que trabalham juntas:

\n
• Polly — biblioteca para implementar padrões de resiliência (Retry, Circuit Breaker, Timeout, Bulkhead Isolation).
\n
• Simmy (Microsoft.Extensions.Resilience) — biblioteca para engenharia do caos, que estende o Polly. Permite "injetar" falhas em suas políticas.
\n

Simmy é o "irmão malvado" do Polly. Se o Polly ensina sua aplicação a sobreviver, o Simmy verifica o quão bem ela faz isso, quebrando intencionalmente as chamadas.

Prática: Configurando um experimento de caos em C#

Vamos ao código. Suponha que temos um serviço de reservas que acessa uma API de pagamento externa. Queremos testar como o BookingService se comportará se a API de pagamento começar a responder com atraso ou erros.

Passo 1: Instalação dos pacotes

dotnet add package Microsoft.Extensions.Http.Polly\ndotnet add package Microsoft.Extensions.Resilience\n

Passo 2: Configuração do HttpClient com políticas

Primeiro, configuramos a política padrão de Circuit Breaker e Retry usando Polly. Em seguida, "envolvemos" ela na política de caos do Simmy.

using Microsoft.Extensions.DependencyInjection;\nusing Microsoft.Extensions.Http.Resilience;\nusing Polly;\nusing Polly.Extensions.Http;\n\npublic static class ServiceCollectionExtensions\n{\n    public static IServiceCollection AddPaymentClient(this IServiceCollection services)\n    {\n        services.AddHttpClient<IPaymentService, PaymentService>(client =&g