¿Qué es el Circuit Breaker?
En pocas palabras, es una especie de disyuntor o un patrón de diseño creado para agregar resiliencia y tolerancia a fallos en sistemas distribuidos. Actúa como un proxy entre el servicio llamador y el servicio destino, impidiendo que fallos en cascada derriben toda la aplicación.
¿El Problema que Resuelve?
En arquitectura de microservicios, cuando un servicio A depende de un servicio B que se vuelve indisponible, el servicio A comienza a acumular hilos bloqueados esperando respuestas que nunca llegan. Esto lleva a un agotamiento de recursos, que a su vez hace que el servicio A también se vuelva indisponible, y así el fallo se propaga en efecto dominó por toda la aplicación. El Circuit Breaker resuelve esto fallando rápidamente en lugar de dejar que la solicitud se bloquee por largos períodos.
Los Tres Estados
| Estado | Comportamiento | Transición |
|---|---|---|
| Closed (Cerrado) | Las solicitudes fluyen normalmente; las fallas se monitorean | -> Open, cuando se alcanza el umbral de errores |
| Open (Abierto) | Las solicitudes se bloquean inmediatamente; devuelve fallback o error | -> Half-Open, después del tiempo de espera de recuperación |
| Half-Open (Medio-Abierto) | Se permite un número limitado de solicitudes de prueba | -> Closed (éxito) o Open (fallo) |
En el estado Closed, el sistema opera normalmente mientras el circuit breaker monitorea la tasa de errores. Si el número de fallos supera un umbral configurado (ej.: 15 fallos en 60 segundos), transita a Open. Después de un período de espera (período de enfriamiento), pasa a Half-Open, donde permite algunas solicitudes de prueba para verificar si el servicio se ha recuperado.
Beneficios y Desafíos
Beneficios
- Previene fallos en cascada
- Mejora la estabilidad general del sistema al reducir la carga sobre servicios fallidos
- Proporciona información sobre la salud y confiabilidad de los servicios
Desafíos
- Configurar los umbrales y tiempos de espera ideales requiere un conocimiento profundo del comportamiento de los servicios
- Requiere estrategias de fallback bien definidas
- El patrón asume que el servicio se recupera con el tiempo, lo que no siempre es cierto
Cuándo Usar
- Llamadas síncronas entre microservicios
- Integraciones con APIs externas o de terceros
- Servicios con alto riesgo de sobrecarga o latencia variable
- Entornos de alta disponibilidad donde el tiempo de inactividad es crítico