Retry Storms

Qué es

Retry Storm es una dinámica de feedback en la que fallos o latencia provocan reintentos que agregan suficiente trabajo para mantener o empeorar la degradación. El sistema recibe más intentos precisamente cuando tiene menos margen para atenderlos; esos intentos generan nuevos fallos que alimentan el siguiente ciclo.

Retry no equivale a Retry Storm. retry es una política de repetición para fallos elegibles, con límites y condiciones de seguridad. La tormenta es un comportamiento emergente bajo determinadas condiciones de carga, capacidad y coordinación. Una repetición aislada que consigue progreso no demuestra una tormenta, ni todo aumento de errores proviene de retries.

dependency slows
    -> timeouts or failures
    -> retries add work
    -> contention and queueing grow
    -> dependency slows further

«Positivo» describe el signo del feedback: el efecto refuerza la perturbación. No expresa un beneficio ni exige que el crecimiento sea infinito. Puede estabilizarse en una demanda adicional alta, con poco trabajo útil completado.

Demanda original y amplificada

Separar intenciones de negocio de intentos físicos permite observar amplificación. Cien compras pueden producir cientos de llamadas a Payment sin representar nuevos compradores. El costo adicional incluye conexiones, serialización, CPU, logging, espera y llamadas internas; contar únicamente solicitudes externas puede ocultarlo.

Un timeout local puede ocurrir mientras el primer intento sigue ejecutándose. Iniciar otro superpone ocupación incluso si el efecto está protegido por idempotency. La seguridad de repetir una escritura no vuelve gratuito su procesamiento ni garantiza que una dependencia tenga capacidad.

overload describe demanda insostenible; Retry Storm describe un mecanismo que la produce o mantiene. Puede empezar por pérdida de capacidad, un pico de tráfico, un error temporal o una política que vence antes de una respuesta normal. No hace falta que todos los clientes reintenten al mismo instante.

Múltiples capas y ownership

Client
    -> hasta 3 intentos hacia Service A
Service A
    -> hasta 3 intentos hacia Service B por invocación
Service B
    -> hasta 3 intentos hacia Database por invocación

Bajo esos supuestos ilustrativos, una intención puede provocar hasta 3 × 3 × 3 = 27 tentativas hacia Database. «Tres» cuenta el intento inicial, no tres repeticiones adicionales. El resultado depende de que cada capa agote su política; éxitos tempranos, presupuesto compartido o cancelación pueden reducirlo. Fan-out y retries internos pueden cambiar el modelo.

AWS Builders’ Library muestra cómo políticas independientes en capas multiplican el trabajo downstream y discute elegir conscientemente dónde repetir. El ejemplo no establece una fórmula universal para cualquier grafo. Timeouts, retries, and backoff with jitter.

Ownership significa conocer quién repite, qué errores interpreta y qué límites conserva. No necesariamente exige un único proceso para toda la cadena, pero sí evitar que aplicación, proxy, SDK y worker concedan cada uno un presupuesto nuevo sin coordinarlo.

Tiempo, cantidad y presupuestos agregados

Limitar intentos por operación controla una secuencia individual. deadline controla cuánto tiempo puede seguir siendo útil. Un retry budget agregado limita trabajo extra de una población: muchos clientes con solo dos tentativas todavía pueden duplicar una carga que ya no cabe.

Google SRE recomienda límites por solicitud y presupuestos de retries por servicio para contener amplificación, además de evitar repetición en varias capas sin coordinación. Addressing Cascading Failures: preventing retries.

Un budget necesita scope, contabilidad y comportamiento al agotarse. Reiniciar cada instancia puede resetear presupuestos y liberar otra oleada. Excluir los retries de una cuota de ingreso permite que tráfico aparentemente permitido produzca una carga final mucho mayor; incluirlos puede consumir la cuota de una operación con resultado incierto. El contrato debe resolver ambas consecuencias.

Espaciamiento y sincronización

Immediate retries vuelven a competir antes de que cambie la condición de fallo. backoff reduce frecuencia individual; jitter distribuye calendarios. Backoff sin variación puede mantener clientes alineados, y un cap temporal sin límite agregado puede sostener presión durante mucho tiempo.

AWS analiza cómo exponential backoff conserva grupos sincronizados y cómo introducir jitter reduce esa concentración en su modelo de contención. No promete que cualquier configuración elimine una tormenta. Exponential Backoff and Jitter.

thundering-herd enfatiza activación simultánea; Retry Storm enfatiza el feedback de repetición. Pueden coexistir, pero una tormenta con clientes desfasados sigue siendo posible y un herd puede estar formado exclusivamente por primeras solicitudes.

Backlog y Messaging

retry-topologies aplica el problema a mensajes que esperan o vuelven a entregarse. Delayed redelivery reduce frecuencia y puede conservar intención, pero acumula una deuda futura. Una dependencia que recupera capacidad puede recibir backlog, tráfico nuevo y retries de varias etapas al mismo tiempo.

Medir edad e intentos a través de colas evita interpretar una cola principal vacía como recuperación. Transferir casos a dead-letter-queue cambia responsabilidad bajo una política; no aumenta capacidad ni demuestra que el negocio terminó. Las intenciones durables necesitan permanecer resolubles cuando se frena el retry automático.

Prevención y recuperación

admission-control puede impedir nuevos compromisos cuando no hay margen; load-shedding puede sacrificar trabajo elegible y observable. bulkhead conserva recursos para otros flujos, aunque una partición saturada todavía puede recibir intentos inútiles. circuit-breaker puede frenar invocaciones sin sustituir clasificación, contabilidad o capacidad de recuperación.

Para recuperar, reducir el trabajo extra que sostiene el ciclo, restaurar capacidad y regular la reintroducción de pendientes. No basta con declarar sana la dependencia si todos los productores liberan sus presupuestos a la vez. Mantener límites durante el drenaje permite comprobar progreso antes de ampliar admisión.

Abandonar una espera no autoriza perder una obligación aceptada. Evitar retries también tiene costo: algunos fallos transitorios no se recuperarán dentro de esa solicitud y habrá que comunicar resultado incierto o delegar reparación. El objetivo es progreso seguro y sostenible, no simplemente reducir un contador de errores.

Reconocimiento y límites

Observar intentos por intención, proporción de carga adicional, motivo de repetición, ejecuciones superpuestas, presupuesto, backlog y éxito atribuible a retries. Latencia creciente junto con más intentos y menos finalizaciones útiles sugiere el loop, pero requiere comprobar causalidad.

Usar el concepto para analizar amplificación de recuperación. No etiquetar como tormenta cualquier retry ni atribuirle todos los problemas de capacidad. Puede alimentar cascading-failures y, si permanece tras retirar el trigger, metastable-failures. failure-dynamics sitúa esas diferencias.