Uber detiene 9,5M de retries con Error Ownership

¿Qué es un retry storm y por qué puede tumbar tu plataforma?

Un retry storm puede multiplicar por 8 el tráfico que recibe un servicio degradado en apenas una cadena de 7 nodos. Cuando el equipo de ingeniería de Uber modeló lo que ocurre cuando un servicio falla y cada caller reintenta una vez, los nodos aguas abajo del origen del error absorbieron 8×N peticiones: lo que empezó como un fallo local amenazaba con convertirse en un incidente stack-wide.

El término retry storm describe exactamente eso: un servicio que empieza a fallar y, en lugar de aliviarse con reintentos, se ahoga bajo el peso de sus propios mecanismos de recuperación. En el ejemplo del propio blog de Uber, una cadena lineal A→B→C→D→E→F→G con un solo reintento por hop termina exponiendo los nodos E, F y G a 8 veces la carga nominal cuando D empieza a devolver errores. La fórmula simplificada: R^d × N, donde R es el número de reintentos y d la profundidad del nodo en la cadena.

Los retry budgets (limitar a un porcentaje fijo los reintentos permitidos) ayudan, pero el propio equipo de Uber reconoce que son «manualmente configurados y carecen de visibilidad sobre la amplificación cross-service». Con un presupuesto del 10%, los nodos E, F y G del ejemplo aún recibían 1,33×N peticiones cuando D fallaba. No resuelven el problema de raíz.

👥 ¿Quieres ir más allá de la noticia?

En nuestra comunidad discutimos las tendencias, compartimos oportunidades y nos ayudamos entre emprendedores. Sin humo, solo acción.

👥 Unirme a la comunidad

Cómo Uber distinguió el síntoma de la causa (Error Ownership)

La clave del nuevo mecanismo de Uber es una pregunta contraintuitiva: ¿quién es dueño del error? Si el servicio S llama a tres servicios downstream y uno falla, el error que devuelve S es solo un síntoma; la causa está en su dependencia caída. Pero si ninguno de sus downstream falla y aún así devuelve un error, entonces S es el dueño.

Uber bautizó esta arquitectura como Error Ownership y la implementó sobre su Service Dependency Analysis Solution (SDAS) combinado con un retry middleware compartido que corre en el request path de sus APIs user-facing. Cuando un servicio downstream devuelve un error, propaga un header x-uber-error-claim:

Claim: «yo causé este error, puedes reintentarme».
Unclaim: «yo solo propagué el error, no me reintentes más».

El caller usa ese header para decidir: si ve «claimed», reintenta; si ve «unclaimed», corta la cadena de reintentos y propaga el error hacia arriba también como «unclaimed». Así, solo el servicio que originó el error recibe reintentos, y todos los ancestros dejan de martillearlo. El sistema además preserva la propiedad de at-least-once retry mediante un flag que indica si los criterios de reintento se cumplen, evitando caídas de disponibilidad por eliminar reintentos legítimos.

Como explica TechTarget en su guía de patrones de microservicios, el retry pattern tradicional (reintentar N veces ante un fallo) funciona bien para errores transitorios pero se vuelve contraproducente cuando el downstream está sobrecargado: cada reintento añade presión al sistema que ya está fallando. Error Ownership formaliza esa distinción en el middleware compartido.

Los números del outage del 18 de noviembre de 2025

El caso real más contundente lo aporta el outage del 18 de noviembre de 2025. Un servicio Core Entity, situado a más de 5 niveles de profundidad en la cadena de llamadas y crítico para operaciones de negocio, empezó a devolver una tasa de error muy alta por un problema de infraestructura subyacente. Según reportó Tom’s Guide, fue una de las mayores caídas de Uber en 2025.

El equipo de ingeniería calcula que, con retry budgets simples, ese día el servicio degradado habría recibido entre un 46% y 135% más tráfico del que ya estaba fallando. Con Error Ownership activado en producción, el sistema contuvo el blast radius de forma automática. Cifras concretas compartidas en el post:

9,5 millones de peticiones espurias detenidas en el service mesh durante el incidente.
Hasta 200.000 peticiones adicionales bloqueadas en los callers inmediatos del servicio degradado.
Max retry storm radius (profundidad máxima donde un storm puede ocurrir) reducido de 25 a 3 en todas las APIs user-facing.
Promedio de retry storm radius reducido de 20 a 2.

Para una plataforma que según datos de la propia compañía coordina un promedio de 42 millones de viajes y pedidos de entrega al día, evitar 9,5 millones de reintentos innecesarios no es elegancia técnica: es la diferencia entre un blip de minutos y un outage prolongado que aparece en titulares.

¿Qué significa esto para tu startup?

No necesitas operar a escala Uber para llevarte algo útil de esta arquitectura. Tres acciones concretas que puedes implementar este trimestre:

Mide el retry storm radius de tu plataforma hoy. Recorre tus cadenas de llamadas más profundas y pregúntate: si un servicio a 5 saltos falla, ¿cuántas veces se reintenta en cada nivel? Si no puedes responderlo en una reunión de arquitectura de 15 minutos, ya tienes un punto de partida. Uber pasó de radio 25 a radio 3: ese es exactamente el tipo de métrica que puedes llevar a tu próximo board de ingeniería.
Piensa en claims, no solo en budgets. Un retry budget global es como un cinturón de seguridad: necesario pero insuficiente. Empieza por etiquetar en tus respuestas HTTP quién originó el error (claim) y quién solo lo propagó (unclaim). Un header simple como X-Error-Owner: <service-name> te da visibilidad para escribir reglas de retry más inteligentes sin tocar el código de negocio.
Diseña para la coincidencia de errores. El equipo de Uber documenta que errores coincidentes (tu servicio falla por sobrecarga de caché al mismo tiempo que un downstream falla por motivos no relacionados) son raros pero catastróficos. Empieza por registrar métricas de correlación: si tu error rate sube a la vez que el de un downstream, probablemente no eres la causa raíz. Una memoria básica de patrones de fallos es el primer paso hacia un sistema similar a SDAS.

El contexto general: si tu startup maneja APIs con latencia crítica, pagos o cadenas de microservicios con tres o más niveles de profundidad, este tipo de mecanismos es lo que separa un incidente de 5 minutos de uno que termina en TechCrunch — o, en el ecosistema hispano, en una nota de elDiarioES o Xataka.