Un proveedor de pagos empieza a responder 500 y tu cola de jobs se infla minuto a minuto. Los workers quedan esperando un timeout de 30 segundos por llamada. Llegan peticiones nuevas, no encuentran worker libre y todo el servicio responde lento. Michael Nygard documentó esa cascada en Release It! (Pragmatic Bookshelf, 2ª ed., 2018); cuatro patrones cortan el efecto antes del colapso.

Circuit breaker en tres estados

El breaker cuenta fallos por dependencia. Sobre el umbral se abre: las llamadas siguientes fallan rápido, sin tocar la red. Pasa el cooldown, el breaker entra en semiapertura y deja atravesar una llamada de prueba. El éxito lo devuelve al estado cerrado; el fallo lo reabre. La implementación vive en el borde de la llamada externa, y el equipo registra la transición de estado como métrica por dependencia. La alerta salta cuando el breaker se abre, no cuando la latencia media sube.

Retry con backoff exponencial y jitter

Un retry inmediato tras un fallo crea una tormenta: mil clientes reentran juntos y tumban el servicio que se estaba recuperando. El backoff exponencial dobla el intervalo en cada intento. El jitter esparce los intentos en el tiempo y evita la sincronización. Solo la operación idempotente entra en el loop de retry: crear un cobro dos veces genera un duplicado; reprocesar un webhook con clave de idempotencia, no. La guía de arquitectura de AWS recomienda jitter aleatorio junto al backoff (AWS, 2015), y la cuenta de sincronización masiva aparece en cualquier incidente de pos Black Friday.

Timeout en toda llamada y bulkhead

El timeout de conexión y el timeout de lectura separan fallo de red de respuesta lenta. El patrón bulkhead aísla recursos por dependencia: pagos usa un pool de 20 threads, email usa otro pool. El fallo de uno no drena al otro. Netflix creó Hystrix para esto y lo retiró en 2018; los equipos Java pasaron a Resilience4j, que compone breaker, retry, bulkhead y rate limiter como funciones independientes. La documentación de Resilience4j (2025) muestra la composición por módulo.

Medir lo que hace el breaker

Registras por dependencia: tasa de error, latencia p99, duración de cada estado del breaker y cuántas llamadas atendió el fallback. Sin eso, el breaker se vuelve una caja negra que falla sola, y nadie sabe si protegió el servicio o escondió el problema. Sam Newman, en Building Microservices (O'Reilly, 2ª ed., 2021), sitúa la resiliencia de dependencias junto a la observabilidad: el patrón paga su costo cuando el equipo ve el fallo y elige el comportamiento de fallback.