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
| Pregunta | Documento | Evidencia que conviene buscar |
|---|---|---|
| ¿El fallo se propaga hacia otros componentes? | cascading-failures | Retención de recursos, transferencia de carga y dependencia causal. |
| ¿Los retries mantienen o agravan la degradación? | retry-storms | Intentos por intención, carga adicional y feedback sobre latencia o fallos. |
| ¿Muchos actores se activan por una condición común? | thundering-herd | Eventos compartidos y concentración temporal de demanda. |
| ¿Desapareció el trigger pero el fallo sigue autosostenido? | metastable-failures | Sustaining effect, estado acumulado y falta de recuperación bajo condiciones restauradas. |
| ¿Cuánto puede quedar afectado? | blast-radius | Població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 functionsEsta 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 overloadSeguir 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 persistsMetastable 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.