El 12 de junio de 2025 Google Cloud tuvo una caída global, con decenas de sus servicios abajo a la vez. A los 40 minutos la mitigación estaba desplegada y las regiones empezaron a recuperarse, las pequeñas primero. Una no: us-central1 no quedó resuelta del todo hasta 2 horas y 40 minutos después de empezar el incidente. Mismo bug, misma gente arreglándolo. Lo que alargó aquella región no fue el fallo: fueron los reintentos.
Este post no va de Google. Va de que ese mismo mecanismo está montado, ahora mismo, en la infraestructura de cualquier empresa con una decena de servidores y tres integraciones: en un cron, en el agente de copias, en el cliente de correo de cada puesto y en el propio sistema de monitorización. Y de que nadie lo ha escrito en ningún sitio, porque el reintento no se decide: viene puesto de fábrica.
Qué pasó exactamente en aquella región
El informe público del incidente cuenta el arranque sin adornos: entró un cambio de política de cuotas con campos en blanco, y esos campos vacíos «recorrieron la ruta de código que topaba con el puntero nulo, provocando que los binarios entraran en un bucle de caídas». Hasta ahí, un bug —y uno que llevaba desplegado desde el 29 de mayo sin protección de feature flag, esperando a que un dato con la forma adecuada lo despertara—. Lo que vino después es lo que nos interesa: al reiniciarse en masa, aquellas tareas «crearon un efecto manada sobre la infraestructura de la que dependen (es decir, esa tabla de Spanner), sobrecargándola». Y una frase que debería estar enmarcada en más salas de máquinas: «Service Control no tenía implementado el backoff exponencial aleatorizado apropiado para evitar esto». (Las citas son traducción nuestra; el informe está en inglés.)
Para salir del agujero tuvieron que hacer lo contrario de lo que pide el instinto: frenar. Estrangularon la creación de tareas y desviaron tráfico a bases de datos multirregionales para bajarle la carga a la que estaba ahogada. Por eso la región grande fue la última en cerrarse: no porque el arreglo fuera más difícil allí, sino porque había que recuperarla despacio para que la recuperación no la volviera a tumbar.
Una tormenta de reintentos es esto: un sistema que ya no puede con la carga recibe más carga precisamente porque no puede. Es el atasco donde todo el mundo toca el claxon. El ruido no despeja la carretera; la colapsa un poco más.
Dónde vive esto si no tienes una región entera
La reacción normal al leer un informe así es «ya, pero eso es a escala de Google». No hace falta escala. Hacen falta dos cosas: un recurso compartido y varias cosas que insistan a la vez. Los sitios donde nos lo encontramos:
- ▸El
cronque tarda más que su intervalo. Se programó cada cinco minutos cuando tardaba dos. Hoy tarda siete porque la tabla ha crecido. A partir de ese día no hay un proceso: hay dos, luego tres, cada uno peleando por el mismo bloqueo de base de datos. Nadie cambió nada; solo creció el dato. - ▸El trabajo de copia que falla y vuelve a entrar. Una ventana de backup que no cierra y reintenta se solapa con la siguiente. Dos pasadas leyendo los mismos discos hacen que la tercera tarde aún más. El síntoma que se ve en el panel no es «la cabina va lenta»: es «los backups tardan cada día un poco más».
- ▸Vuelve la luz y arranca todo a la vez. Es el efecto manada de la pyme. Sesenta equipos, veinte máquinas virtuales y un par de servicios pidiendo DNS, controlador de dominio y licencias en el mismo segundo. El corte duró cuatro minutos; volver a trabajar, cuarenta.
- ▸La monitorización, que aprieta justo cuando duele. En la familia Nagios/Icinga hay dos intervalos: el normal y el de reintento, que entra cuando un chequeo acaba de ponerse en mal estado y que casi siempre se configura más corto. Son unos pocos sondeos —los que van del estado SOFT al HARD, hasta agotar
max_check_attempts, y después se vuelve al intervalo normal—, así que no es una tormenta. Pero es tu sistema de vigilancia empujando en la misma dirección que todos los demás, y conviene saberlo antes de bajar el intervalo «para enterarnos antes». - ▸Y el reintento humano. Cuando algo no carga, la gente pulsa F5. Cuarenta personas pulsando F5 es una prueba de carga no autorizada contra un servidor que ya estaba pidiendo auxilio.
En ninguno de estos cinco casos hay nada moderno: ni microservicios, ni nada que suene a conferencia. Hay una tabla, una cabina o un controlador de dominio, y varias cosas insistiendo encima a la vez. Que es exactamente la receta de us-central1, solo que con tres ceros menos.
La multiplicación que nadie diseñó
Hay una cuenta en el libro de SRE de Google que conviene tener a mano cuando alguien propone «pues que reintente, por si acaso». Si la base de datos no da abasto, y el backend, el frontend y el JavaScript del navegador hacen cada uno 3 reintentos —4 intentos—, una sola acción de un usuario puede acabar en 64 intentos contra la base de datos (4³). Nadie diseñó 64. Cada capa puso un 3 defensivo, sin saber lo que hacían las otras, y los treses se multiplicaron en vez de sumarse.
Lo que dice el capítulo es más blando de lo que nos gustaría: piensa en el servicio como un todo, decide si de verdad necesitas reintentar en ese nivel y, sobre todo, «evita amplificar los reintentos lanzándolos en varios niveles». Nuestra regla es más dura, y la firmamos como nuestra: reintenta en un solo sitio, el de más arriba, y deja que el fallo suba limpio por las capas de abajo. Un error que llega rápido al usuario es información. Un error que rebota diez veces por el camino es carga.
Los cuatro números que hay que tener escritos
No es un proyecto. Son cuatro valores que alguien tiene que decidir y dejar por escrito, y que hoy en la mayoría de sitios están donde los dejó el instalador:
- 1El tiempo de espera. Sin un timeout explícito no hay reintento que valga: hay conexiones colgadas acumulándose hasta que se agota el pool. Un tiempo de espera es la promesa de soltar el recurso aunque la respuesta nunca llegue.
- 2El tope de intentos. Google usa un presupuesto de hasta tres intentos por petición; si ha fallado tres veces, dejan que el error suba a quien hizo la llamada. El razonamiento es sencillo: si una petición ha caído tres veces en tareas saturadas, es poco probable que la cuarta arregle algo.
- 3La espera creciente y aleatoria. «Usa siempre backoff exponencial aleatorizado al planificar reintentos», dice el libro. Lo importante de esa frase no es «exponencial»: es «aleatorizado». Si mil clientes esperan exactamente un segundo, dentro de un segundo tendrás mil clientes otra vez. La aleatoriedad es lo que reparte la manada; es exactamente la pieza que faltaba en la región que tardó 2 h 40.
- 4El presupuesto global. El tope por petición no basta, porque muchas peticiones con tope pequeño siguen sumando. Por eso, en Google, cada cliente vigila qué proporción de su tráfico son reintentos y solo reintenta mientras esa proporción esté por debajo del 10%. La cifra publicada es contundente: con topes por petición, el crecimiento en el peor caso se queda algo por debajo de 3x; añadiendo el presupuesto del 10%, en el caso general baja a 1,1x. La versión para quien no tiene ese mecanismo: «como mucho 60 reintentos por minuto en un proceso; superado eso, no reintentes, falla».
Cuatro números. Ninguno cuesta dinero. Lo que cuesta es la conversación de decidirlos, porque obliga a admitir que hay peticiones que es mejor dejar caer.
Cuándo NO tocar los reintentos
Diríamos una tontería si el mensaje fuera «quita los reintentos». Un reintento bien puesto es lo que hace que un microcorte de red no llegue nunca al usuario. Pero hay dos operaciones que no admiten reintento automático y conviene tenerlas escritas antes que los cuatro números: las que no se pueden repetir sin consecuencias —un cobro, un envío de pedido, un correo: si no puedes garantizar que repetirla es inocua, el reintento no te da resiliencia, te da duplicados que alguien limpiará a mano— y los errores que no van a cambiar: un 401 o un 404 no mejoran por insistir. Reintentar sirve para lo transitorio, no para un «no» firme.
Y hay una tercera cosa que no haríamos: montar una plataforma para arreglar esto. Aquí discrepamos del discurso habitual. No hace falta una malla de servicios, ni un producto de resiliencia, ni un rediseño. Hacen falta cuatro valores decididos y un inventario de quién reintenta a quién. Si alguien te vende lo primero antes de que hayas escrito lo segundo, te está vendiendo la parte cara.
El peor momento no es la caída: es el arranque
Lo que hace especial al caso del 12 de junio es que la tormenta no ocurrió durante el fallo, sino al volver. Todo arrancó a la vez y se pisó. Y esa es justo la parte que nadie ensaya, porque los simulacros suelen medir «cuánto tardo en restaurar» y casi nunca «qué pasa cuando 200 cosas vuelven a la vez y todas quieren autenticarse, resolver nombres y leer del mismo sitio».
Nosotros cronometramos recuperaciones completas de forma periódica —el último simulacro interno salió en 14 minutos, y lo contamos como prueba, no como promesa contractual— y lo que se aprende ahí no es el tiempo: es el orden. Qué tiene que estar en marcha antes que qué, qué conviene arrancar escalonado y qué integración se pone nerviosa si su dependencia tarda treinta segundos de más. Ese orden se escribe una vez y vale para el resto de sustos. Sobre por qué un plan sin ensayar es literatura, ya lo contamos en el plan de continuidad que nadie ha ensayado.
Hay un parentesco evidente con la alta disponibilidad: un clúster tampoco evita la caída, la acorta. El reintento es lo mismo al revés: no evita el fallo y, mal puesto, lo alarga.
Cinco preguntas para la próxima reunión
Con una regla: «sí» no cuenta como respuesta. La respuesta es un número o un sitio donde está escrito.
- 1.¿Cuántas capas hay entre el usuario y la base de datos, y cuántas de ellas reintentan? Si nadie lo sabe, el número real es el producto, no la suma.
- 2.¿Qué trabajos programados tardan hoy más de lo que dura su intervalo? Es una consulta, no una opinión: la duración media está en el histórico.
- 3.¿Las esperas entre reintentos llevan aleatoriedad, o todos los clientes vuelven en el mismo segundo?
- 4.¿Qué operaciones NO deben reintentarse nunca automáticamente? Si la lista está vacía, es que no se ha mirado.
- 5.Cuando vuelve la luz, ¿qué arranca primero y qué espera? Si la respuesta es «todo a la vez», ya tienes escrita la próxima incidencia.
Lo incómodo del asunto
Un estudio ya clásico sobre por qué fallan los grandes servicios de internet (Oppenheimer, Ganapathi y Patterson, USENIX 2003) situó el error del operador —y dentro de él, en más de la mitad de los casos, los errores de configuración— en cabeza de las caídas de servicio en dos de los tres servicios que estudió. Con un matiz que los propios autores subrayan y que ya contamos al hablar de por qué la redundancia no sobrevive al procedimiento: no es que el operador falle más que el hardware, es que sus errores se enmascaran menos. La redundancia tapa el disco muerto; no tapa al que toca producción. Veintitantos años después, la fotografía de junio de 2025 rima: un cambio de configuración con campos vacíos, una ruta de código sin proteger y, sobre todo, una decisión que nadie tomó —cómo se reintenta— alargando el peor caso hasta las dos horas y cuarenta.
El fallo es inevitable. La avería —que tu empresa deje de funcionar, y durante cuánto— sigue siendo una decisión de diseño. Los reintentos son de esas decisiones que se toman solas si no las toma nadie.
En everyWAN esto lo miramos donde se ve: en la plataforma que sostiene las aplicaciones de negocio (datos y aplicaciones), en la infraestructura que hay debajo (infraestructura y cloud) y en la monitorización que tiene que distinguir un servicio lento de un servicio que se está ahogando por insistencia propia. Usamos Zabbix y SmokePing, con una regla que se nos nota: alertas que importan, no ruido.
Fuentes (verificadas el 28-sep-2026): informe público del incidente de Google Cloud del 12 de junio de 2025 —bucle de caídas, efecto manada sobre Spanner, ausencia de backoff exponencial aleatorizado y tiempos de recuperación por región— status.cloud.google.com; presupuesto de tres intentos, ratio de reintentos del 10% y crecimiento de 3x a 1,1x — Google SRE Book, «Handling Overload»; multiplicación 4³ = 64 intentos, backoff exponencial aleatorizado, presupuesto de 60 reintentos por minuto y reintentar en un solo nivel — Google SRE Book, «Addressing Cascading Failures»; causas de caída en grandes servicios — Oppenheimer, Ganapathi y Patterson, Why Do Internet Services Fail, and What Can Be Done About It?, USENIX 2003. El dato de 14 minutos es un simulacro interno de everyWAN: una medición, no un compromiso de servicio.
¿Sabes cuántas cosas reintentan contra tu base de datos ahora mismo?
Lo miramos contigo: quién reintenta a quién, qué trabajos se solapan y en qué orden tiene que volver todo después de un corte. Sin vendernos una plataforma por el camino.
Hablar con everyWAN
Microsoft 365
ES 
CAT 
EN