Circuit Breaker es un patrón arquitectónico para prevenir errores en cadena y la degradación de sistemas distribuidos. Su esencia es: un componente encargado de realizar llamadas a un sistema externo verifica el éxito de las operaciones. Si el número de intentos fallidos se vuelve demasiado alto, el Circuit Breaker se "abre" automáticamente y las llamadas subsiguientes no se procesan hasta que el sistema comience a recuperarse.
Ejemplo: si el microservicio Auth deja de responder, el servicio Order, utilizando el Circuit Breaker, no envía solicitudes temporalmente y devuelve un error de inmediato, previniendo una alta carga en el sistema dependiente.
Ejemplo de código en Python (usando la biblioteca pybreaker):
import pybreaker import requests breaker = pybreaker.CircuitBreaker(fail_max=3, reset_timeout=30) @breaker def call_service(): return requests.get("https://api.service.com/data") try: response = call_service() except pybreaker.CircuitBreakerError: print("Servicio temporalmente no disponible. Por favor, inténtelo más tarde.")
Características clave:
¿Circuit Breaker es lo mismo que Retry?
No. Retry repite las operaciones fallidas, mientras que Circuit Breaker rompe la cadena de llamadas al detectar una alta cantidad de fallos, dando un respiro al sistema. Con mayor frecuencia, estos patrones se combinan: retry adentro, circuit breaker afuera.
¿Es necesario implementar Circuit Breaker entre nuestros propios microservicios que se despliegan simultáneamente?
Sí, si los servicios pueden experimentar fallos de tolerancia a fallos o fallos de red. Nadie está exento de errores de configuración o carga, incluso tus microservicios.
¿El Circuit Breaker solo es necesario en integraciones de API externas?
No, este patrón se puede aplicar a cualquier interacción poco fiable, incluyendo dentro de tu propia infraestructura: bases de datos, caché, colas de mensajes.