Este incidente en Uber ilustra un problema clásico en sistemas distribuidos a gran escala: las 'retry storms' o tormentas de reintentos. Cuando un servicio en una cadena de dependencias profunda comienza a fallar, los servicios upstream, configurados para reintentar, amplifican exponencialmente la carga sobre el servicio ya degradado, así como sobre sus propias dependencias. Esto puede convertir una falla localizada en una interrupción a nivel de stack, impactando severamente la experiencia del usuario.
La causa raíz del problema es la falta de 'context-awareness' en el comportamiento de reintento tradicional. Los reintentos se aplican uniformemente sin distinguir si un error es una causa original o simplemente un síntoma de una falla más profunda. Los 'retry budgets' mitigan parcialmente esto, pero no resuelven la amplificación en cadenas de dependencia profundas. La incapacidad de escalar la traducción de códigos de error específicos a través de múltiples capas de servicios con alto fan-in/fan-out es un factor clave que impide soluciones más simples.
La salvaguarda fallida aquí es la configuración de reintentos estándar que, si bien es útil para fallas transitorias de baja tasa, se vuelve contraproducente durante degradaciones significativas. La solución de Uber, 'Error Ownership', aborda esto al establecer qué servicio es el 'dueño' de un error (la causa original vs. un síntoma propagado). Al incrustar esta lógica en el 'retry middleware' y el 'Service Dependency Analysis Solution', se permite que los reintentos ocurran solo donde pueden ser efectivos (en el servicio que realmente causó el error), evitando la amplificación innecesaria en los servicios upstream. Este enfoque transformó un potencial aumento de tráfico del 46%-135% en el servicio degradado en una contención efectiva, deteniendo millones de solicitudes espurias.