Circuit Breaker

Resumen

Cuando un servicio A llama al servicio B y B empieza a fallar, A tiene dos opciones: seguir intentando y acumular timeouts, consumiendo recursos y propagando la falla hacia arriba —falla en cascada—, o dejar de intentar durante un tiempo y devolver un error rápido o un valor por defecto. El Circuit Breaker implementa la segunda opción.

Funciona como un interruptor eléctrico con tres estados:

• Cerrado (Closed): las llamadas pasan normalmente. El breaker monitorea fallas y, si superan un umbral, se abre.
• Abierto (Open): las llamadas se rechazan inmediatamente sin intentar contactar al servicio fallido. Después de un tiempo de espera, pasa a semi-abierto.
• Semi-abierto (Half-Open): se permite una cantidad limitada de llamadas de prueba. Si tienen éxito, el breaker se cierra. Si fallan, se vuelve a abrir y se reinicia el contador de espera.

Alcance y supuestos

Este paquete cubre el concepto a nivel arquitectónico: qué es, qué problema resuelve, cómo se relaciona con otros patrones del ecosistema, y en qué contexto tiene sentido aplicarlo. No cubre detalles de implementación específicos de cada tecnología ni configuraciones de proveedores cloud concretos. Asume que el lector entiende los fundamentos de sistemas distribuidos y arquitectura de software.

Modelo mental

El fusible de una casa. Si conectás demasiados electrodomésticos y el circuito se sobrecarga, el fusible salta y corta la electricidad. No se queda ahí para siempre: podés volver a subirlo después de un rato. Pero si apenas lo subís vuelve a saltar, sabés que el problema sigue y lo dejás apagado hasta resolver la causa. El Circuit Breaker es un fusible para las llamadas entre servicios.

Uso práctico

• ✅ Evita fallas en cascada: un servicio lento no arrastra a todos los que dependen de él.
• ✅ Recuperación rápida: en lugar de esperar timeouts de 30 segundos, el breaker responde en milisegundos cuando está abierto.
• ✅ Monitoreo: el estado del breaker es una métrica clave de salud del sistema.
• ❌ No reemplaza timeouts y retries: es una capa adicional, no un sustituto.

Implementaciones: Polly (.NET), Resilience4j (Java), failsafe (Java), Netflix Hystrix (obsoleto pero influyente), y la mayoría de los service meshes (Istio, Linkerd) lo incluyen.

Ejemplo trabajado: circuit breaker entre servicios

El servicio recommendation-service depende de product-catalog. Un pico de tráfico satura product-catalog y empieza a responder con timeouts. El circuit breaker de recommendation-service detecta 50% de fallas en 10 segundos y se abre. Durante 30 segundos, las llamadas a product-catalog se rechazan inmediatamente y recommendation-service devuelve una lista de recomendaciones cacheadas. Después de 30 segundos, el breaker pasa a half-open y permite 3 requests de prueba. Si product-catalog se recuperó, el breaker se cierra. Si no, se vuelve a abrir. Los usuarios vieron recomendaciones cacheadas en vez de un error 500.

Evidencia

• Wikipedia, Circuit breaker design pattern describe los tres estados del patrón, su origen en el libro Release It! de Michael Nygard y su adopción en sistemas distribuidos modernos.