Variación aleatoria entre reintentos

Retry jitter introduce aleatoriedad en la espera antes de una nueva llamada. Distribuye en el tiempo los intentos de varios clientes. Resulta especialmente útil cuando muchos clientes detectan el mismo fallo a la vez: una pausa idéntica puede limitarse a posponer el siguiente pico de carga.

Tres clientes, esperas distintas

En un ejemplo ficticio, tres clientes pueden elegir cada uno una espera aleatoria dentro de una ventana de 0–2 s antes del siguiente intento. Esperan, por ejemplo, 0.4 s, 1.1 s y 1.7 s. Estos valores ilustran la distribución; no son una configuración recomendada. Los intentos pueden seguir coincidiendo pese a la variación aleatoria.

La estrategia de reintentos sigue determinando qué errores justifican otro intento, cuántos se permiten y cuándo termina el plazo total. Deben respetarse las instrucciones del sistema de destino sobre los tiempos de espera. Con el retroceso exponencial, el intervalo de espera suele aumentar con los siguientes intentos hasta un límite configurado; jitter varía la pausa efectiva según la regla utilizada.

La aleatoriedad no hace segura la repetición de una operación. Una respuesta perdida puede ocultar una escritura ya completada. Antes de volver a intentarlo, la integración necesita una regla de repetición segura, como la idempotencia o la comprobación del resultado.

Fuentes

• AWS Builders’ Library: Timeouts, retries, and backoff with jitter

• AWS Architecture Blog: Exponential Backoff And Jitter