Retry Pattern

Resumen

En sistemas distribuidos, muchas fallas son transitorias: un paquete de red se pierde, un servicio está momentáneamente saturado, una conexión de base de datos expiró. El patrón Retry reintenta la operación fallida, asumiendo que la causa de la falla es temporal y que el reintento tiene altas probabilidades de éxito.

No todo error se debe reintentar. Si la operación falló porque el request era inválido —un 400—, reintentar solo repite la misma falla. Si falló porque el servicio está caído, reintentar inmediatamente solo agrega carga. El patrón Retry debe combinarse con:

• Backoff: esperar entre reintentos, con tiempo creciente —exponencial, lineal, o aleatorio—.
• Jitter: agregar variación aleatoria al tiempo de espera para evitar que múltiples clientes reintenten al mismo tiempo —thundering herd—.
• Límite: un número máximo de reintentos para no reintentar indefinidamente.

Alcance y supuestos

Este paquete cubre el concepto a nivel arquitectónico: qué es, qué problema resuelve, cómo se relaciona con otros patrones del ecosistema, y en qué contexto tiene sentido aplicarlo. No cubre detalles de implementación específicos de cada tecnología ni configuraciones de proveedores cloud concretos. Asume que el lector entiende los fundamentos de sistemas distribuidos y arquitectura de software.

Modelo mental

Llamar por teléfono a alguien que no atiende. Si no atiende la primera vez, esperás unos minutos y volvés a llamar. Si sigue sin atender, esperás más —quizás una hora—. No llamás 50 veces en un minuto, ni dejás de llamar para siempre después del primer intento. El retry pattern es esa estrategia: reintentar con criterio.

Uso práctico

• ✅ Fallas transitorias: timeouts de red, conexiones agotadas, rate limiting con header Retry-After.
• ✅ Idempotencia: reintentar solo es seguro si la operación es idempotente o si usás idempotency keys.
• ❌ Fallas permanentes: no reintentar errores 400, 401, 403, ni operaciones que ya tuvieron efecto pero se perdió la respuesta.
• ❌ Sin límite: reintentar infinitamente transforma una falla transitoria en una permanente.

Implementaciones: Polly (.NET), Resilience4j (Java), tenacity (Python), axios-retry (JS).

Ejemplo trabajado: retry con backoff en una integración de pagos

Un servicio llama a la API de un proveedor de pagos externo. El proveedor responde con timeout el 2% de las veces. El servicio implementa retry con backoff exponencial y jitter: primer reintento a los 100 ms, segundo a los 200 ms, tercero a los 400 ms. Con 3 reintentos, la tasa de fallas efectiva pasa de 2% a 0.0008%. El servicio también usa idempotency keys para evitar cobros duplicados si la respuesta del proveedor se pierde después de un cobro exitoso.

Evidencia

• AWS Well-Architected Framework, Reliability Pillar recomienda el patrón Retry con backoff exponencial y jitter como práctica estándar de resiliencia.