Qué es el backoff exponencial y cómo usar reintentos

Un reintento puede ayudar cuando la falla es transitoria: una conexión se corta, un servicio devuelve un límite temporal o una dependencia tarda más de lo esperado. Repetir no arregla una operación inválida ni una credencial vencida. La primera decisión es clasificar la respuesta y definir qué errores se pueden volver a intentar.

También puede servirte: Qué es la degradación gradual en sistemas y cómo diseñarla

El backoff exponencial aumenta la espera después de cada intento fallido. Una secuencia puede empezar con una pausa breve y duplicarse hasta alcanzar un máximo. El objetivo es reducir la presión sobre la dependencia mientras se recupera, no hacer que el usuario espere sin límite.

Si muchos clientes fallan al mismo tiempo y todos siguen la misma secuencia, pueden volver a enviar solicitudes juntos. El jitter agrega una variación aleatoria dentro de un rango para repartir esos intentos. AWS y Google Cloud lo recomiendan como parte de una estrategia que combina pausas, límites y una lectura cuidadosa del error.

La espera inicial debe considerar el timeout real, el costo de la operación y la ventana en la que una recuperación tiene sentido. Un límite superior evita que una secuencia crezca sin control. También conviene definir un tiempo total, porque contar intentos sin contar la espera puede ocultar una demora muy larga.

Primero preguntá si la falla es transitoria y si el servidor ofrece una señal para esperar, como un estado de límite o un encabezado de reintento. Después comprobá que repetir no duplique una compra, un envío o una mutación. Para operaciones no idempotentes, es preferible una clave de deduplicación o una confirmación explícita antes de intentar otra vez.

La política debe fijar intentos máximos, demora máxima, timeout total y una condición de abandono. Registrá cada intento con su causa, duración y resultado. Una métrica de éxito posterior no alcanza: también hay que observar rechazos, latencia, carga y solicitudes que quedaron sin completar.

Probá por separado una desconexión breve, un límite temporal, una respuesta lenta y un error permanente. Verificá que el cliente no reintente códigos que requieren corregir la petición y que respete el límite del servidor. En una cola, comprobá además que los mensajes no se multipliquen cuando un consumidor vuelve a tomar trabajo.

gRPC documenta controles de retry y observabilidad para conocer qué llamadas fueron reintentadas y cuál fue su resultado. La recuperación debe medirse en condiciones acotadas antes de ampliar el tráfico. Si el servicio vuelve pero la dependencia sigue saturada, el backoff debe ceder y dejar visible el error en lugar de insistir.