Reintentos: cuándo te salvan y cuándo empeoran las cosas
Por El equipo de Atflow
Reintentar una operación fallida es el patrón de fiabilidad más común y uno de los más fáciles de hacer catastróficamente mal. Bien hecho, los fallos transitorios desaparecen antes de que nadie se dé cuenta. Mal hecho, tus propios clientes acaban con un servicio que ya estaba luchando por sobrevivir.
Reintenta solo lo que se puede reintentar
Un timeout merece un reintento; un 400 no, y nunca lo merecerá. Reintentar un fallo determinista es solo una forma más lenta de fallar que además genera carga. La primera decisión es siempre si esa clase de error puede tener éxito en un segundo intento.
Las reglas que importan
- Backoff exponencial con jitter — los reintentos sincronizados son una estampida autoinfligida.
- Un límite estricto de intentos y un destino definido para lo que los agote.
- Idempotencia, o tu reintento cobrará al cliente dos veces.
- Un circuit breaker, para dejar de martillear algo que claramente está caído.
Son decisiones de política, no detalles de código, y por eso merecen estar en un lugar visible. Una rama de reintento con «+72 h, máx. 3» escrito encima se puede auditar; una constante enterrada en un servicio, no.