Tiempos de espera, reintentos y backoff con jitter

Objetivo

Hacer que un cliente resista fallos transitorios sin amplificar una interrupción ni duplicar trabajo.

Requisitos previos

Conocer qué operaciones son idempotentes (o están protegidas por claves de idempotencia) y qué señala el servidor ante una sobrecarga (429 o 503 con Retry-After).

Pasos

1. Establecer un tiempo de espera de conexión y un tiempo de espera de lectura en cada llamada remota; elegirlos a partir del plazo propio del llamante, no del caso más lento observado.
2. Reintentar solo ante resultados transitorios: errores de conexión, tiempos de espera agotados, 429, 503, 502/504 de intermediarios. Nunca reintentar ante errores de validación 4xx.
3. Reintentar solo operaciones idempotentes, u operaciones con una clave de idempotencia; un POST simple se reintenta únicamente si el servidor documenta un comportamiento idempotente.
4. Espaciar los reintentos exponencialmente (base × 2^intento) con jitter aleatorio, tal como recomienda el análisis de AWS citado, y acotar tanto el retardo como el número de intentos.
5. Respetar Retry-After cuando el servidor lo envíe; este valor prevalece sobre el retardo calculado.
6. Añadir un disyuntor (circuit breaker) o un presupuesto para que una dependencia con fallos no consuma toda la capacidad del cliente.

Resultado esperado

Los clientes se recuperan automáticamente de interrupciones breves, la carga sobre un servidor que se recupera aumenta de forma gradual, y ninguna operación se ejecuta dos veces por accidente.

Límites y base de verificación

Los reintentos añaden latencia; las rutas interactivas pueden preferir fallar rápido. Los parámetros de backoff necesitan ajustarse por dependencia. Las recomendaciones siguen las fuentes citadas y la práctica del cliente de ejemplo de este wiki.

Cabeceras informativas de límite de tasa

Algunos servidores anuncian sus límites antes de emitir un 429. Un borrador del IETF (draft-ietf-httpapi-ratelimit-headers) define un campo RateLimit que lleva la cuota restante y los segundos hasta que se reinicia, y un campo RateLimit-Policy que describe la política; otros servidores envían cabeceras específicas del proveedor con el mismo significado. Cuando estos campos están presentes, conviene leerlos y reducir el ritmo antes de que la cuota llegue a cero, no después; tratarlos como indicios que pueden estar ausentes o cambiar de forma, y mantener el backoff de los pasos 4 y 5 como respaldo. Nunca dejar que una cabecera informativa eleve la tasa de solicitudes por encima de lo que permite el propio presupuesto del llamante.