Resilience Patterns
Esta vista organiza decisiones sobre espera, repetición, aislamiento y respuestas bajo fallas o demoras. Los nueve canónicos conservan las definiciones y mecanismos; el MOC permite recorrerlos a partir de una pregunta de diseño.
Preguntas de entrada
| Pregunta | Recorrido |
|---|---|
| ¿Cuánto puedo esperar en un punto y hasta cuándo dispone de tiempo la operación completa? | timeout y deadline |
| ¿Debo intentarlo otra vez y bajo qué condiciones? | retry |
| ¿Cuándo debo volver a intentarlo sin concentrar tráfico? | backoff y jitter |
| ¿Debo dejar temporalmente de llamar a esta dependencia? | circuit-breaker |
| ¿Cuánta capacidad puede consumir esta dependencia o categoría de trabajo? | bulkhead |
| ¿Puedo degradar funcionalidad o debo comunicar indisponibilidad? | fallback |
| ¿Puedo reducir tail latency mediante ejecución especulativa segura? | hedged-requests — avanzado |
Recorrido: respuesta perdida
Empezar por Timeout para distinguir el fin de la espera local del estado remoto. Seguir por idempotency y Retry antes de repetir: la operación pudo completarse y el resultado ser desconocido. Deadline permite comprobar si consultar o intentar otra vez todavía tiene sentido dentro del presupuesto del caller.
La seguridad del efecto y la disponibilidad son preguntas diferentes. Una repetición segura puede consumir recursos innecesarios; una dependencia recuperada puede recibir una repetición insegura. reliable-execution sitúa estas decisiones junto a las garantías de entrega y los efectos observables.
Recorrido: dependencia sobrecargada
Revisar primero qué fallos justifican Retry y quién es responsable de hacerlo. Después recorrer Backoff y Jitter para evaluar tanto la frecuencia individual como la sincronización de la población. Circuit Breaker agrega una decisión de admisión cuando continuar llamando deja de ser útil.
Bulkhead ayuda a conservar capacidad para otros trabajos; Fallback permite evaluar una respuesta alternativa válida y sostenible. Esa alternativa también puede fallar o saturarse. Hedged Requests merece una evaluación separada: duplicar trabajo sobre un sistema ya saturado puede agravar el problema.
Recorrido: lentitud ocasional en lecturas
Leer primero Deadline y Timeout; después comprobar la semántica de Idempotency. Hedged Requests permite evaluar una segunda ejecución mientras la primera sigue activa. Antes de usarlo, revisar consistencia del resultado, independencia de destinos, carga adicional y cancelación cooperativa del perdedor. Es una optimización avanzada, no el siguiente paso automático después de Retry.
Combinación sin receta fija
Los patrones pueden cooperar, pero no forman una pila obligatoria:
- Deadline y Timeout: un presupuesto total contiene las esperas y límites por intento.
- Retry, Backoff y Jitter: una repetición elegible se espacía dentro de ese presupuesto y de un límite de carga adicional.
- Circuit Breaker y Fallback: un rechazo puede activar una alternativa; el breaker no define su corrección.
- Bulkhead: cada intento o alternativa consume la capacidad correspondiente; separar cuotas no vuelve saludable una dependencia.
- Hedged Requests: la tentativa especulativa comparte Deadline y necesita capacidad propia, sin convertirlo en un retry secuencial.
El orden importa. Un breaker que observa cada intento recibe evidencia distinta de uno que observa solo el resultado final; un fallback que oculta el fallo también cambia esa evidencia. Definir qué ve cada control y qué protege antes de combinarlos.
Puentes y límites
- at-least-once: otra entrega posible no determina cómo repetir, cuánto esperar o cómo proteger el efecto.
- reliable-messaging: el relay de transactional-outbox y la política previa a dead-letter-queue necesitan decisiones de Retry. El trabajo duradero puede continuar después del presupuesto de una solicitud HTTP.
- distributed-transactions: saga-pattern utiliza recuperación hacia adelante cuando un paso puede completarse más tarde; conservar la intención sigue siendo necesario.
retry-topologies es una perspectiva de Retry desde Messaging: conecta la política con residencia del mensaje, redelivery y ordering. load-and-flow-control organiza las decisiones ante overload, desde nuevos compromisos hasta espera y presión upstream. admission-control, load-shedding y backpressure complementan repetición y aislamiento cuando sus contratos lo permiten; espaciar intentos no crea capacidad ni define qué obligación puede descartarse.
failure-dynamics permite comprobar consecuencias de políticas mal ajustadas: retry-storms para amplificación, thundering-herd para sincronización, cascading-failures para propagación y metastable-failures para persistencia tras retirar el trigger. blast-radius ayuda a evaluar cuánto impacto alcanza una configuración o fallo. La combinación de un timeout corto y retries agresivos puede añadir carga en vez de recuperar disponibilidad.
Las políticas deben explicar qué protegen, qué rechazan y qué resultado presentan al caller. El cluster ofrece criterios para esas decisiones; la ubicación física organiza el contenido y no define identidades ni relaciones.