Retry

Qué es

Retry vuelve a intentar una operación después de un fallo o un resultado incierto, con la expectativa de que otro intento pueda completar la misma intención. La política decide qué repetir, quién lo hace, cuándo, cuántas veces y bajo qué condiciones deja de intentarlo.

Retry no es recuperación automática ni una solución universal. Puede superar un fallo transitorio, repetir un efecto ya confirmado o agravar una sobrecarga. Que una llamada sea técnicamente repetible no significa que convenga ejecutarla otra vez.

timeout aporta evidencia de que una espera venció, no de que el efecto remoto esté ausente. deadline limita el tiempo total; idempotency ayuda a proteger efectos cuando se repite una intención. Son responsabilidades distintas de la decisión de reintentar.

Qué problema resuelve

Una conexión interrumpida o un recurso temporalmente no disponible pueden hacer fallar una operación correcta. Si el sistema vuelve a estar disponible y el caller conserva la intención, un intento posterior puede conseguir progreso sin intervención.

Un error permanente de validación no cambia porque pasen unos milisegundos. Tampoco una dependencia saturada obtiene capacidad simplemente por recibir más llamadas. Azure distingue fallos transitorios de persistentes y advierte sobre el costo de políticas agresivas. Retry pattern.

Condiciones para un retry seguro y útil

Antes de habilitarlo, responder:

• Resultado anterior: ¿hay evidencia de que no hubo efecto, o permanece desconocido?
• Seguridad: ¿la operación es idempotente en su efecto relevante, el receptor reconoce la intención o existe otra coordinación que evita duplicarla?
• Recuperabilidad: ¿la causa puede cambiar sin alterar la solicitud, o necesita corrección previa?
• Tiempo y carga: ¿queda presupuesto y la dependencia puede tolerar otro intento?
• Vigencia: ¿la intención y sus parámetros siguen siendo válidos?

Un código de error genérico no responde todas estas preguntas. Incluso un error del servidor puede ocurrir después de confirmar datos. Cuando no es seguro repetir, consultar el resultado, reconciliar o escalar puede ser la recuperación adecuada.

Una librería puede conocer casos de transporte donde la aplicación remota no vio el intento; eso no autoriza a trasladar esa certeza a cualquier timeout. gRPC distingue retries transparentes de políticas que admiten más situaciones, con límites y códigos elegibles. gRPC: Retry.

Identidad de operación y efectos

La identidad de la intención permanece entre intentos. Cada intento puede tener su propio identificador de observabilidad, pero no debe crear accidentalmente una segunda compra o reserva. Reutilizar la misma identidad con parámetros incompatibles tampoco es un retry válido.

Si Order Service pierde la respuesta de reserve-order-42, repetir bajo un contrato durable de idempotency puede devolver o completar la reserva existente. Reenviar «restar una unidad» sin protección puede volver a descontar stock. La memoria del receptor debe cubrir el horizonte de reintentos admitido y coordinarse con el efecto.

Idempotencia limita duplicación, no garantiza orden ni que el intento termine. at-least-once admite repeticiones precisamente para recuperar entrega; los efectos siguen necesitando un contrato propio.

Bounded retries y retry budgets

Una operación interactiva necesita límites de intentos y tiempo. «Tres intentos totales» incluye el original; «tres retries» permite cuatro intentos. Esa diferencia debe quedar clara en configuración, pruebas y métricas.

Antes de cada intento se comprueban cancelación, deadline, espera prevista y presupuesto de carga. Un máximo de intentos no protege la latencia si cada intento puede esperar indefinidamente. Un deadline tampoco limita el número agregado de llamadas que muchos clientes pueden enviar simultáneamente.

Un retry budget agregado restringe cuánto trabajo extra puede generar un proceso o servicio, por ejemplo mediante una tasa acotada o una proporción del tráfico original. Es distinto del presupuesto temporal. Google SRE recomienda límites por solicitud y presupuestos agregados para contener la amplificación. Addressing Cascading Failures: retries.

En trabajo durable, agotar el lote de intentos de un worker no obliga a borrar la intención. Puede mantenerse pendiente, reprogramarse bajo otra política o transferirse a inspección. No debe confundirse terminar una llamada con abandonar silenciosamente una obligación ya aceptada.

Retry ownership y amplificación

Elegir un dueño que conozca el contexto evita que aplicación, cliente, proxy y dependencia repitan todos la misma operación sin coordinarse. Hay que inspeccionar los retries que ya realiza cada capa.

Si tres capas permiten dos intentos cada una, una sola operación puede producir hasta ocho intentos en la capa final. Limitar únicamente el bucle exterior no elimina esa multiplicación. Además, un timeout puede dejar el intento anterior activo mientras empieza el siguiente. Esa carga adicional puede provocar o sostener overload: la lentitud genera más retries y estos reducen el margen para recuperar trabajo útil. retry-storms describe esa dinámica emergente y la distingue de una repetición elegible que sí consigue progreso.

La política puede distribuirse si existe un contrato claro entre capas; «un dueño» no exige un único proceso para todo el sistema. Lo necesario es preservar límites, identidad y responsabilidad, y evitar duplicación accidental de políticas.

Cuándo volver a intentar

backoff determina el espaciamiento; jitter distribuye temporalmente clientes que podrían reintentar juntos. No hacen segura una escritura ni justifican continuar después del deadline.

Un circuit-breaker abierto puede rechazar antes de invocar la dependencia. Repetir ese rechazo en un bucle inmediato no la recupera y puede desperdiciar recursos locales. La política debe respetar su estado y las señales de espera que el servicio realmente comunica.

Failure scenarios y operación

Situación	Decisión necesaria
Respuesta perdida tras un efecto	Consultar o repetir con protección de identidad y efecto.
Payload inválido	Corregir o resolver; repetir sin cambios no ayuda.
Dependencia sobrecargada	Reducir trabajo extra y aplicar presupuesto, no acelerar intentos.
Deadline agotado	No iniciar otra tentativa para esa respuesta.
Fallo persistente	Conservar diagnóstico y definir responsable de recuperación.

Medir intentos originales y adicionales, causas, latencia total, éxito obtenido por retries y consumo del budget. Mirar solo el resultado final puede ocultar una dependencia degradada que recibe varias veces la carga normal. quality-attribute-trade-offs permite contrastar recuperación, tiempo y carga bajo escenarios diferentes, en vez de equiparar más retries con más reliability.

Cuándo usarlo y relaciones

Usarlo para fallos elegibles donde repetir es seguro, la intención sigue vigente y hay una posibilidad razonable de progreso. No usarlo para esconder defectos de negocio, retención insuficiente de identidades o falta permanente de capacidad.

saga-pattern puede reintentar pasos durante forward recovery; transactional-outbox puede reintentar publicaciones con la misma identidad. dead-letter-queue permite separar casos agotados bajo una política, pero no prueba que la intención terminó. resilience-patterns organiza esas decisiones junto al tiempo disponible y la protección de dependencias.

retry-topologies aplica este canónico a Messaging: examina dónde espera el mensaje, quién programa la reentrega y qué cambia en ordering y responsabilidad operacional.