Metastable Failures

Qué es

Metastable Failure es una condición degradada que continúa autosostenida después de desaparecer el evento que empujó al sistema fuera de su régimen saludable. Un mecanismo interno de feedback mantiene trabajo excesivo, eficiencia insuficiente o ambos. Retirar el trigger deja de ser suficiente para recuperar progreso útil.

Es una lectura avanzada: requiere distinguir demanda original, trabajo amplificado, capacidad efectiva y estado acumulado. Metastability no equivale a «el sistema está lento». La propiedad decisiva es la persistencia causada por un efecto que sostiene el fallo, no únicamente duración elevada o muchas alertas.

Bronson y colaboradores introducen el marco de trigger y sustaining effect y distinguen regímenes estable, vulnerable y de fallo metastable. El régimen vulnerable puede atender normalmente y, aun así, no recuperarse de determinadas perturbaciones. Metastable Failures in Distributed Systems, HotOS 2021.

Trigger y efecto que sostiene

traffic spike
    -> queue grows
    -> latency grows
    -> timeouts / retries
    -> effective work grows
spike disappears
    -> feedback still adds work or reduces capacity
    -> degraded regime persists

En un feedback positivo, el efecto refuerza la perturbación: más espera añade trabajo o reduce capacidad, y eso produce todavía más espera. No requiere crecimiento ilimitado; puede mantener un régimen degradado.

El trigger puede aumentar tráfico, reducir capacidad o cambiar temporalmente una condición necesaria. El sustaining effect mantiene la dificultad después: tentativas adicionales, cache que no se reconstruye, contención o costo creciente de gestionar el fallo. Son responsabilidades analíticas diferentes, aunque participen los mismos componentes.

El estudio de Huang y colaboradores distingue amplificación de workload y degradación amplificada de capacidad. También observa combinaciones de ambos mecanismos. Esa distinción permite preguntar si el sistema recibe más trabajo que antes o procesa el mismo trabajo de manera menos eficiente. Metastable Failures in the Wild, OSDI 2022.

«Autosostenido» no significa que toda actividad pueda mantenerse eternamente sin solicitudes ni recursos. La demanda original puede continuar en su ritmo normal. Lo que desaparece es la perturbación inicial; las condiciones normales ya no bastan para sacar al sistema del estado degradado.

Estados operativos y memoria del incidente

Un sistema puede atender una determinada carga cuando está caliente y sin backlog, pero no recuperarla desde colas llenas y recursos agotados. Su respuesta depende de cómo llegó al estado actual, no solo de la tasa externa presente. Los regímenes saludable y degradado pueden persistir bajo condiciones externas comparables.

Eso no obliga a suponer estados perfectamente estacionarios ni múltiples equilibrios matemáticos en cualquier implementación. El marco operativo distingue funcionamiento normal, vulnerabilidad a triggers y degradación autosostenida. «Vulnerable» tampoco equivale automáticamente a overload actual: puede existir margen para servir tráfico normal, pero no para absorber la amplificación que dispara un fallo.

El umbral suficiente para evitar la transición puede ser distinto del necesario para salir de ella. Reducir tráfico hasta el valor anterior puede dejar insuficiente margen para completar pendientes y desactivar los loops. La recuperación exige observar estado y progreso, no declarar resuelto el incidente porque la entrada volvió a su promedio.

Ejemplo de retries

Supongamos Order → Payment con 100 intenciones/s y capacidad aproximada de 120 intentos/s. En estado saludable cada intención necesita una tentativa. Un pico temporal de 300 llena la cola y eleva la latencia por encima del timeout.

Bajo el supuesto ilustrativo de que cada intención original ahora dispara un segundo intento, volver a 100 intenciones/s mantiene alrededor de 200 intentos/s mientras continúan esas expiraciones. La presión efectiva permanece por encima de 120 y la latencia sigue justificando más repetición. retry-storms actúa como sustaining effect.

No es una predicción universal: éxito temprano, budgets y cancelación pueden romper el loop. El ejemplo muestra por qué quitar el pico no necesariamente recupera el régimen anterior. Los permisos físicos pueden seguir presentes y, aun así, el trabajo adicional consumir el margen destinado a respuestas útiles.

Un backlog finito que se drena con capacidad excedente representa recuperación lenta, no necesariamente metastabilidad. Para justificar esta última hay que identificar qué mantiene el estado degradado cuando se restauran las condiciones externas, en lugar de inferirlo solo por una cola grande.

Cache, queueing y agotamiento

Una cache fría puede aumentar consultas a una DB. Si las consultas fallan antes de producir valores reutilizables, la cache permanece fría y sigue enviando demanda a la DB. El estado interno evita restaurar la eficiencia previa. El modelo de OSDI recoge este tipo de sustaining effect; no exige que todo fallo metastable involucre retries. Metastable Failures in the Wild.

Queueing también puede reducir capacidad efectiva: más objetos pendientes elevan presión de memoria y trabajo de garbage collection; ese costo ralentiza procesamiento, acumula más pendientes y completa el feedback. La investigación de USENIX documenta y reproduce esa interacción en un caso de producción. Metastable Failures in the Wild: GC.

Añadir memoria o cambiar un timeout no elimina por definición el mecanismo. Puede ampliar margen y ser suficiente para un caso, o solo desplazar el umbral. El costo de logging, coordinación y recuperación puede seguir creciendo aunque se haya reparado la dependencia que inició el incidente.

Prevención frente a recuperación

admission-control, queue-management y presupuestos de retry pueden limitar cuánto estado y trabajo adicional se acumulan. load-shedding puede reducir demanda efectiva, y circuit-breaker frenar algunas invocaciones. Estas medidas necesitan scopes y señales adecuados; no garantizan protección contra cualquier sustaining effect desconocido.

Prevenir la entrada y sacar al sistema del régimen degradado son problemas diferentes. HotOS subraya esa separación y propone revisar el feedback que sostiene el fallo, en lugar de corregir únicamente triggers conocidos. Metastable Failures in Distributed Systems.

Para recuperar, identificar qué trabajo debe dejar de entrar, qué capacidad necesita restablecerse y qué backlog puede drenarse con margen. Mantener protegida la reconstrucción de cache o la finalización de trabajo puede importar más que aceptar solicitudes nuevas durante unos minutos.

Drain, reset y restart

Drenar no significa borrar obligaciones. Se puede pausar admisión, terminar pendientes válidos, expirar trabajo descartable por contrato o transferir responsabilidad durable. Eliminar arbitrariamente una cola puede quitar presión a costa de pérdida de negocio, sin constituir recuperación correcta.

Un reset o restart puede liberar un estado acumulado concreto, pero también enfriar caches, resetear budgets y reencolar ejecuciones. Si el feedback permanece, el sistema puede regresar al mismo régimen. Reiniciar toda la flota simultáneamente puede añadir thundering-herd y empeorar la entrada.

La acción debe corresponder al mecanismo identificado y preservar identidad de efectos inciertos. Reabrir progresivamente admisión y observar si disminuyen edad, carga extra y presión permite verificar una recuperación sostenible.

Reconocimiento y trade-offs

Comparar demanda original, intentos, costo por intento, capacidad efectiva y goodput antes y después de retirar el trigger. Buscar un loop causal; descartar recursos todavía dañados, tráfico externo que no volvió a su valor previo y backlog que simplemente se está drenando.

Usar este concepto para analizar persistencia autosostenida y probar recuperación bajo estado adverso. No tratar cada incidente largo como metastable. Más margen reduce eficiencia económica; shedding afecta disponibilidad y coordinar recuperación añade complejidad. cascading-failures describe propagación y blast-radius su alcance; pueden coexistir con metastabilidad sin definirla. failure-dynamics organiza esas preguntas.