Chaos Engineering para C#: rompiendo aplicaciones para salvar el negocio

Introducción: Por qué su servicio C# no es un mecanismo perfecto

Imagine: escribió un microservicio elegante en C#. El código pasó la revisión de código, las pruebas unitarias cubren el 95%, las pruebas de integración están en verde. Lo despliega a producción y… después de 3 horas el sistema se cae. ¿La razón? Un aumento inesperado de tráfico que sobrecargó el grupo de subprocesos, o una desconexión repentina de la base de datos que no previó.

Bienvenido al mundo real, donde Chaos Engineering (ingeniería del caos) se convierte no en un lujo, sino en una necesidad. No se trata de "romper todo por diversión". Es una disciplina que ayuda a identificar puntos débiles en sistemas distribuidos antes de que sus usuarios los descubran.

En este artículo, analizaremos cómo aplicar Chaos Engineering para aplicaciones C#: desde la teoría hasta ejemplos de código reales utilizando las bibliotecas Polly y Simmy. Aprenderá cómo introducir caos deliberadamente en servicios .NET para aumentar su resiliencia y previsibilidad.

¿Qué es Chaos Engineering y por qué es importante para .NET?

Chaos Engineering es la práctica de realizar experimentos en un sistema distribuido para verificar su capacidad de soportar fallos inesperados. Netflix, Amazon, Microsoft — todos los gigantes lo utilizan. Para los desarrolladores de C#, esto es especialmente relevante, ya que .NET Core/5+ se usa cada vez más para construir servicios en la nube de alta carga en Microsoft Azure.

Principios básicos de la ingeniería del caos:

\n
• Definición del "steady state" (estado estable) — cómo se comporta su sistema en condiciones normales (latencia, throughput, tasa de error).
\n
• Formulación de una hipótesis — "Si la base de datos OrderDB falla, el servicio de pedidos continuará respondiendo con datos en caché durante 5 minutos".
\n
• Introducción del caos — realmente desconecta OrderDB durante 30 segundos.
\n
• Verificación de la hipótesis — revisamos las métricas. Si la hipótesis no se confirma, tiene un error en la arquitectura.
\n

La palabra clave aquí es "experimento". No solo espera lo mejor, demuestra que su sistema sobrevivirá.

Herramientas para Chaos Engineering en C#

En el mundo .NET, existen dos herramientas potentes que funcionan juntas:

\n
• Polly — biblioteca para implementar patrones de resiliencia (Retry, Circuit Breaker, Timeout, Bulkhead Isolation).
\n
• Simmy (Microsoft.Extensions.Resilience) — biblioteca para ingeniería del caos que extiende Polly. Permite "inyectar" fallos en sus políticas.
\n

Simmy es el "hermano malvado" de Polly. Si Polly enseña a su aplicación a sobrevivir, Simmy verifica qué tan bien lo hace, rompiendo deliberadamente las llamadas.

Práctica: Configuración de un experimento de caos en C#

Pasemos al código. Supongamos que tenemos un servicio de reservas que se comunica con una API de pagos externa. Queremos verificar cómo se comportará BookingService si la API de pagos comienza a responder con retrasos o errores.

Paso 1: Instalación de paquetes

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

Paso 2: Configuración de HttpClient con políticas

Primero, configuramos la política estándar de Circuit Breaker y Retry con Polly. Luego, la "envolvemos" en una política de caos de 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