Failure Dynamics

Este mapa organiza preguntas sobre amplificación, sincronización, propagación, persistencia y alcance del impacto. Empezar por el comportamiento observado y seguir las relaciones que ayuden a explicar su mecanismo. Los canónicos contienen definiciones, supuestos y trade-offs.

Preguntas para navegar

PreguntaDocumentoEvidencia que conviene buscar
¿El fallo se propaga hacia otros componentes?cascading-failuresRetención de recursos, transferencia de carga y dependencia causal.
¿Los retries mantienen o agravan la degradación?retry-stormsIntentos por intención, carga adicional y feedback sobre latencia o fallos.
¿Muchos actores se activan por una condición común?thundering-herdEventos compartidos y concentración temporal de demanda.
¿Desapareció el trigger pero el fallo sigue autosostenido?metastable-failuresSustaining effect, estado acumulado y falta de recuperación bajo condiciones restauradas.
¿Cuánto puede quedar afectado?blast-radiusPoblación, funciones, datos, componentes y duración del impacto.

Las preguntas pueden describir partes del mismo incidente. Varios fallos no demuestran una cascada; una ráfaga no demuestra retries; una recuperación lenta no demuestra metastabilidad. El alcance del impacto tampoco indica por sí solo probabilidad.

Recorrido: dependencia que pierde capacidad

dependency slows
    -> timeouts
    -> retry feedback adds work
    -> overload
    -> degradation propagates
    -> impact reaches more users or functions

Esta dinámica es posible si las políticas y recursos permiten amplificación y propagación. Revisar Retry Storms y Cascading Failures para justificar esos pasos. Blast Radius evalúa el alcance resultante; no representa necesariamente otra falla al final de la cadena.

timeout limita espera local y puede dejar trabajo remoto activo. retry decide si repetir; backoff y jitter espacian y distribuyen tentativas. En resilience-patterns, revisar qué observa y protege cada mecanismo antes de combinarlos.

El API que deja de responder puede ser el síntoma final de una DB lenta y de pools agotados en servicios intermedios. Buscar el inicio y los mecanismos de propagación por separado, sin asumir que el último componente visible contiene la causa original.

Recorrido: recuperación que sincroniza

dependency becomes available
    -> blocked clients / reconnects / probes activate together
    -> concentrated demand
    -> possible new overload

Seguir Thundering Herd para revisar el evento común. Luego recorrer admission-control y rate-limiting si la demanda supera lo atendible. Distribuir activaciones no sustituye límites agregados y cerrar un circuit-breaker no garantiza capacidad para todo el backlog.

bulkhead permite preguntar qué otros flujos conservan capacidad. Una recuperación que comparte recursos o mueve tráfico a destinos sin margen puede ampliar Blast Radius.

Recorrido: el trigger ya desapareció

temporary traffic spike or capacity loss
    -> backlog / retries / reduced efficiency
trigger removed
    -> sustaining feedback remains
    -> degraded regime persists

Metastable Failures ayuda a distinguir persistencia autosostenida de una cola finita que se está drenando. Buscar qué rompe el loop: reducir demanda efectiva, restaurar capacidad o permitir reconstrucción de estado. Restart y borrado de backlog no son respuestas generales.

queue-management y load-shedding ayudan a revisar espera y sacrificios permitidos. Una obligación durable no desaparece porque estorbe a la recuperación.

Puentes y límites

load-and-flow-control organiza decisiones sobre aceptación, tránsito, presión y trabajo pendiente. overload describe demanda insostenible; aquí se examina cómo puede iniciarse, amplificarse, extenderse o persistir. backpressure requiere comprobar dónde upstream realmente reacciona.

retry-topologies aplica repetición y backlog a Messaging. reliable-messaging permite conservar responsabilidades de publicación, procesamiento y recuperación. dead-letter-queue no constituye una solución general a estas dinámicas ni aumenta throughput.

Los loops descritos son posibilidades, no una cadena causal universal. El MOC mantiene navegación y síntesis; los conceptos vecinos aún no materializados se explican localmente cuando hacen falta, sin anticipar nuevos documentos.