Uber desarrolla mecanismo para protegerse contra "tormentas de reintentos" en su infraestructura
La compañía implementó un sistema de "propiedad del error" que identifica qué servicios generan fallos y cuáles solo los propagan, evitando reintentos en cascada que colapsan la infraestructura.
Uber publicó un análisis técnico detallando cómo protege su infraestructura contra "retry storms" (tormentas de reintentos), un fenómeno que históricamente ha impactado sus operaciones comerciales y la confianza en su marca. El problema ocurre cuando un fallo en un servicio profundo de la arquitectura desencadena reintentos exponenciales en cascada: en una cadena con un reintento por nodo, si un servicio a profundidad 3 falla, los nodos upstream pueden servir hasta 8 veces más solicitudes de lo normal, sobrecargando servicios ya comprometidos y acelerando el colapso.
La raíz del problema, según el equipo de ingeniería de Uber, es que los reintentos tradicionales carecen de contexto: no distinguen entre errores generados por un servicio y aquellos simplemente propagados a través de él. Esto lleva a reintentos uniformes que, durante degradaciones moderadas o severas, aumentan la carga sobre servicios que ya están fallando, amplificando el tráfico de reintentos a lo largo de la cadena de dependencias. Lo que comienza como una interrupción localizada puede escalar rápidamente a un incidente que afecta a toda la infraestructura.
La solución implementada por Uber establece "error ownership" (propiedad del error), un mecanismo que correlaciona errores de entrada y salida para determinar si un servicio es la causa o solo el síntoma de un fallo. Usando su Service Dependency Analysis Solution, la compañía estableció reglas simples: si un servicio no tiene errores en sus llamadas salientes pero retorna error, ese servicio es el propietario del error; si retorna error porque una llamada saliente falló, solo propaga el error sin reclamarlo. Los servicios upstream solo reintentan cuando el downstream no reclama el error como propio.
El análisis de seis meses de datos de producción reveló que los errores coincidentes —donde tanto el servicio como sus dependencias fallan simultáneamente por razones independientes— son extremadamente raros. En el peor escenario analizado, para el 80% de los bordes con más de 100 fallos del receptor por minuto, solo alrededor del 2% de las veces el servicio llamador también falló de forma coincidente. Esta rareza estadística valida la efectividad del enfoque.
El esquema de error ownership está completamente implementado y operacional en la malla de servicios de Uber, ejecutándose en el middleware de reintentos y en la solución de análisis de dependencias que procesan el tráfico de las APIs de cara al usuario. Como está embebido en infraestructura compartida, los servicios heredan protección contra tormentas de reintentos automáticamente, sin necesidad de lógica personalizada de manejo de errores por servicio. El sistema garantiza al menos un reintento donde sea necesario mientras limita el radio de impacto cuando ocurren disturbios, transformando lo que serían tormentas en perturbaciones localizadas y manejables.
Cuando un servicio falla en una arquitectura de microservicios (muchos servicios pequeños conectados entre sí), los servicios que dependen de él intentan enviar la solicitud de nuevo (reintento). El problema: si cada servicio reintenta automáticamente, una sola falla puede multiplicarse exponencialmente y saturar toda la infraestructura. Uber resolvió esto haciendo que cada servicio marque si generó el error o solo lo está pasando de otro servicio; los servicios solo reintentan contra quien realmente falló, no contra quien simplemente transmitió la mala noticia.
Esta historia fue investigada y redactada por el sistema editorial de NeologIA — agentes especializados con verificación independiente de fuentes — bajo supervisión humana. Cómo trabajamos →