¿Qué es un Circuit Breaker? Cómo evitar fallos en cascada (Cascading Failures)

En sistemas distribuidos y arquitecturas de microservicios, el escenario más peligroso no es que un servicio caiga por completo, sino que se vuelva lento. Un servicio caído devuelve Connection Refused al instante y libera recursos; en cambio, un servicio lento asfixia silenciosamente a todos los sistemas que lo llaman.

La trampa del servicio lento y el Cascading Failure

Imagina que un servicio de pagos o envíos pasa de responder en 150ms a tardar 15 segundos por un bloqueo en la base de datos:

1. Agotamiento del Pool de Hilos (Thread Pool Exhaustion): El API Gateway asigna un hilo por cada petición entrante y queda bloqueado esperando respuesta.
2. Acumulación de colas: Llegan cientos de peticiones nuevas cada segundo mientras ningún hilo se libera durante 15 segundos. En pocos instantes, la memoria y los hilos del servidor se agotan por completo.
3. Efecto Dominó (Cascading Failure): Endpoints que no tienen nada que ver con ese servicio (como "Búsqueda de productos" o "Perfil de usuario") dejan de responder por falta de hilos disponibles.

La solución: El patrón Circuit Breaker (Disyuntor)

Al igual que el disyuntor eléctrico de una casa corta la corriente ante una sobrecarga para evitar un incendio, el patrón Circuit Breaker envuelve las llamadas a servicios externos y monitorea la tasa de fallos y tiempos de espera en tres estados:

1. Closed (Cerrado — Flujo normal)

El tráfico fluye con normalidad hacia el servicio destino. En segundo plano se registran las métricas de error (5xx) y timeout. Mientras no se supere el umbral (por ejemplo, 50 %), el circuito permanece cerrado.

2. Open (Abierto — Fail-Fast y Fallback)

Cuando la tasa de fallos supera el umbral, el disyuntor salta al estado Open.

• Las peticiones no se envían al servicio lento.
• En lugar de esperar 15 segundos, el sistema responde en 1ms (Fail-Fast) o ejecuta un Fallback (por ejemplo, devolviendo datos en caché desde Redis).
• Así se protegen los recursos del sistema principal y se da respiro al servicio saturado.

3. Half-Open (Semiabierto — Prueba controlada)

Tras un tiempo de espera (resetTimeout, p. ej. 30 segundos), el circuito pasa a Half-Open.

• Solo se permite el paso de unas pocas peticiones de prueba.
• Si responden con éxito, el circuito vuelve a Closed (Self-Healing). Si fallan, regresa inmediatamente a Open.

En producción, herramientas como Resilience4j (Java), Polly (.NET), Opossum (Node.js) o Envoy / Istio Service Mesh implementan este patrón de forma nativa.