¿Por qué los reintentos ingenuos empeoran una caída y cómo diseñarías una política de reintentos segura?

Los reintentos ingenuos multiplican la carga justo cuando un servicio ya está sufriendo, y los clientes sincronizados reintentan en oleadas acompasadas. Usa backoff exponencial con jitter completo, limita el total de intentos y reintenta solo operaciones idempotentes ante errores reintentables. Añade un presupuesto de reintentos en el cliente para que los reintentos sigan siendo una fracción pequeña del tráfico, más un circuit breaker que corte las llamadas del todo cuando la tasa de fallo se dispara. Nunca reintentes de forma independiente en cada capa de la pila.

El problema es que los reintentos son carga extra aplicada en el peor momento posible. Si un servicio falla al 50% y cada cliente reintenta tres veces, acabas de triplicar el tráfico que golpea algo que ya está por encima de su capacidad, y nunca tiene ocasión de recuperarse. El backoff exponencial a secas tampoco basta, porque todos tus clientes fallaron en el mismo instante, así que todos se despiertan en el mismo instante. El jitter completo lo arregla: la espera es un valor aleatorio entre cero y el techo de backoff actual. Más allá de eso, solo reintentaría llamadas idempotentes, solo ante 503, 429 y errores a nivel de conexión, nunca ante un 400, y aplicaría un presupuesto de reintentos para que estos queden limitados a algo así como el 10% del total de peticiones. La que nos mordió fue el apilamiento por capas. El SDK reintentaba tres veces, la malla reintentaba dos y el ejecutor de trabajos reintentaba otra vez, o sea dieciocho intentos para una sola llamada lógica.