Cómo una restricción de cuenta en Google Cloud provocó la gran caída de Railway del 19 de mayo

Por qué desaparecieron servicios clave

El problema no se limitó a una sola máquina o servicio. La restricción afectó a componentes fundamentales de la infraestructura que Railway utilizaba tanto para ejecutar cargas de trabajo de clientes como para operar su propio sistema interno.

Según la actualización de Railway, el estado restringido eliminó simultáneamente varios elementos esenciales:

• CloudSQL, donde se almacenaban datos de la plataforma
• La API de Railway, dependencia central del sistema
• Máquinas virtuales “overflow”, utilizadas para capacidad adicional de cómputo

Cuando la API desapareció, se perdió una dependencia crítica del plano de control de la plataforma. Eso provocó que múltiples sistemas que dependían de ella dejaran de funcionar.

Sin esos servicios, Railway no pudo operar con normalidad:

• el panel de control y el sistema de login
• los flujos de despliegue
• el enrutamiento hacia aplicaciones en ejecución
• la construcción y provisión de nuevas cargas de trabajo

Como resultado, tanto la interfaz para desarrolladores como las aplicaciones alojadas quedaron inestables o inaccesibles durante la ventana de la caída.

Por qué el fallo se propagó por toda la plataforma

El incidente no se limitó a los recursos eliminados inicialmente. Se extendió porque las capas de orquestación y enrutamiento de Railway dependían de esos servicios ahora inaccesibles.

Durante la recuperación, los ingenieros indicaron que algunos usuarios podían restaurar sus aplicaciones volviendo a desplegarlas, lo que permitía que la plataforma redirigiera el código a máquinas sanas cuando la infraestructura volvía a estar disponible.

Esto sugiere que el plano de control responsable de programar, enrutar y reconstruir cargas de trabajo no podía recuperarse completamente de forma automática mientras ciertos recursos de Google Cloud permanecían bloqueados.

Algunas explicaciones dentro de la comunidad señalaron que el impacto también alcanzó cargas de trabajo ejecutadas fuera de Google Cloud —por ejemplo en AWS o en hardware propio de Railway— porque el estado de enrutamiento de la plataforma no podía actualizarse. Sin embargo, el mecanismo técnico exacto de ese efecto en cascada no ha sido confirmado públicamente en un postmortem completo.

La lección sobre el “multi‑cloud”

Uno de los aspectos más comentados del incidente fue la lección arquitectónica que dejó.

Railway opera infraestructura en varios entornos, incluyendo AWS y hardware dedicado, pero el evento mostró que la resiliencia real depende de dónde reside el plano de control. Si la orquestación, la identidad, el enrutamiento o las bases de datos dependen de una sola cuenta de proveedor, ese proveedor se convierte en un punto único de fallo.

Perder el acceso a la cuenta significó perder no solo capacidad de cómputo, sino también los sistemas que:

• registran despliegues
• gestionan el enrutamiento
• aprovisionan infraestructura
• permiten recuperar cargas de trabajo

Esa dependencia permitió que una única restricción se propagara por toda la plataforma.

Debate sobre las restricciones automáticas en la nube

El incidente también generó debate sobre los sistemas automáticos de cumplimiento y seguridad de los grandes proveedores cloud.

Las plataformas cloud pueden restringir o suspender cuentas automáticamente ante señales como problemas de facturación, posibles violaciones de políticas o riesgos de seguridad. En este caso, sin embargo, no se ha confirmado públicamente qué desencadenó exactamente la restricción de Google Cloud, lo que deja abierta la posibilidad de múltiples causas.

El episodio destacó dos riesgos operativos importantes:

• Las acciones automáticas sobre cuentas pueden desactivar infraestructura crítica de forma inmediata.
• Incluso clientes con soporte empresarial pueden enfrentar demoras mientras el proveedor investiga el motivo de la restricción.

Lo que aún no se sabe

A pesar de las actualizaciones de Railway y los análisis de la comunidad, todavía quedan preguntas abiertas:

• La razón exacta por la que Google Cloud restringió la cuenta de producción
• El mapa completo de dependencias internas entre CloudSQL, la API, el enrutamiento y la infraestructura de cómputo
• Si algunos efectos en cascada fueron confirmados internamente o deducidos por observadores

Hasta que se publique un análisis técnico completo del incidente, la explicación pública sigue siendo una reconstrucción basada en reportes disponibles.

Una advertencia para las plataformas en la nube

La caída de Railway del 19 de mayo subraya una realidad clave de la infraestructura moderna: las dependencias del plano de control pueden ser más críticas que la diversidad de infraestructura.

Ejecutar cargas de trabajo en múltiples nubes no garantiza resiliencia si los sistemas que gestionan despliegues, identidad, enrutamiento y orquestación dependen de una sola cuenta de proveedor. Cuando ese nivel desaparece —aunque sea temporalmente— toda la plataforma puede quedar fuera de línea.

Para startups y proveedores de infraestructura, el incidente recuerda un desafío de ingeniería conocido pero a menudo subestimado: evitar puntos únicos de fallo ocultos en los sistemas que controlan todo lo demás.