By Grego — yoDEV
El lunes 19 de mayo a las 22:20 UTC, mis aplicaciones dejaron de responder. No fue un bug mío. No fue un deploy roto. Fue Google Cloud.
Esa noche, los sistemas automatizados de Google Cloud colocaron incorrectamente la cuenta de producción de Railway en estado suspendido — sin previo aviso, sin revisión humana, sin una sola notificación. El incidente duró aproximadamente 8 horas y afectó a todos los clientes de Railway en todas las regiones. Incluyendo todos los que, como yo, tenían sus apps corriendo ahí.
Lo que pasó esa noche es uno de los casos más claros que vi en años sobre por qué la concentración de dependencias en un solo proveedor cloud es un riesgo operacional real — no un escenario hipotético de arquitectura.
Lo que pasó, técnicamente
El postmortem publicado por Railway el 20 de mayo es uno de los más honestos que leí en mucho tiempo. Lo que describe es una falla en cadena que cualquier arquitecto debería estudiar.
La suspensión automatizada de GCP deshabilitó el dashboard, la API y el plano de control de red de Railway — todo alojado en Google Cloud. Hasta ahí, era una falla de un proveedor. El problema real vino después.
Los edge proxies de Railway mantienen una caché de las tablas de ruteo, que se populan desde ese plano de control alojado en GCP. Mientras la caché aguantó, los workloads en Railway Metal y AWS siguieron funcionando. Cuando la caché expiró, el mesh no pudo re-popular las rutas — y los workloads en todas las regiones, incluso los que corrían en AWS y Metal y no tenían nada que ver con GCP, empezaron a devolver 404.
Una sola dependencia en el hot path de descubrimiento de red se convirtió en un single point of failure para toda la plataforma.
Para colmo, cuando Google restauró el acceso a la cuenta, los servicios individuales no se restauraron automáticamente. Discos, compute instances y networking requirieron recuperación separada. La restauración de networking y edge routing tardó hasta aproximadamente la 01:30 UTC del 20 de mayo — más de tres horas después del inicio. Y cuando el sistema volvió, el volumen de retries saturó las integraciones OAuth y webhooks de GitHub, bloqueando logins y builds durante otra hora adicional.
El propio founder de Railway, Jake Cooper, calificó el comportamiento de Google como “gobsmacking” — que un proveedor con el que gastaban más de 10 millones de dólares en Cloud ejecutara una suspensión automatizada masiva sin revisión humana ni comunicación previa es, efectivamente, difícil de procesar.
El verdadero problema no es Google
Sería fácil convertir esto en una nota de “Google malo, Railway víctima”. Pero Railway misma lo puso en términos muy distintos en su postmortem:
“Railway owns our vendor choices, and we ultimately own this one.”
Y tienen razón. El problema arquitectural preexistía a esta suspensión. El plano de control de red — la pieza que decide hacia dónde va el tráfico — tenía una dependencia dura con GCP. Eso es una decisión de diseño. No fue Google quien la tomó.
Para los que gestionamos plataformas y servicios, el aprendizaje no es “no uses Railway” ni “no uses Google Cloud”. El aprendizaje es: ¿dónde están tus dependencias en el hot path?
No alcanza con tener workloads distribuidos en múltiples clouds si el plano de control que los conecta vive en uno solo. Alta disponibilidad multi-AZ dentro de un proveedor no es lo mismo que resiliencia ante la pérdida total de ese proveedor.
Qué está haciendo Railway
El postmortem detalla tres medidas concretas:
1. Eliminar la dependencia dura de GCP en el plano de control de red. El objetivo es convertir la red en un mesh verdadero, donde si cualquier interconexión falla, siempre exista un path alternativo entre los clouds.
2. Extender los shards de base de datos de alta disponibilidad a AWS y Metal. Si todas las instancias de un cloud desaparecen de golpe, el quorum de la base de datos mantiene todo funcionando y hace failover de inmediato.
3. Sacar a Google Cloud del hot path del plano de datos y del plano de control. GCP quedaría relegado a rol secundario/failover mientras se implementa una nueva arquitectura para ambos planos.
Son exactamente las medidas correctas. Pero llevará tiempo.
Lo que esto debería disparar en tu organización
Si tus aplicaciones estuvieron caídas ese lunes a la madrugada, y sos el responsable de plataforma o infraestructura, este incidente es el caso de negocio que necesitabas para la conversación que venías postergando sobre DRP y multi-provider.
Algunos ejes concretos para evaluar:
Mapeá tus dependencias en el hot path. No los workloads — las dependencias de control y descubrimiento. ¿Dónde vive tu plano de control? ¿Qué pasa si ese proveedor desaparece durante 8 horas?
Revisá tu SLA real vs el SLA contractual. Google Cloud tiene SLAs del 99.9% para muchos servicios. Pero un SLA no te devuelve las 8 horas caídas ni los clientes perdidos. El SLA cubre créditos de billing, no impacto de negocio.
Considerá la concentración de proveedor como riesgo operacional. No como decisión técnica — como riesgo a reportar y gestionar. El PaaS que elegís para deployar no es solo una herramienta de productividad; es infraestructura crítica.
Definí qué nivel de multi-provider tiene sentido para tu contexto. No es lo mismo una startup de 3 personas que una plataforma con SLA comprometido con clientes. Pero ambas necesitan tener la respuesta clara antes de que llegue el incidente.
La ironía de todo esto es que Railway es precisamente una plataforma diseñada para que vos no tengas que preocuparte por infraestructura. Y aun así, una decisión automatizada de un proveedor upstream los dejó sin servicio durante 8 horas. El riesgo de dependencia no desaparece por abstraerlo — se traslada.
El cierre
Esta nota la empecé a escribir con mis apps todavía caídas. La termino con una convicción renovada sobre algo que sabía pero que la urgencia cotidiana tiende a postergar: la resiliencia no es un proyecto para cuando tengamos tiempo. Es la deuda técnica que más duele cuando vence.
Railway va a salir de esto con una arquitectura mejor. La pregunta es si vos vas a salir con una estrategia de DRP más clara.
Fuentes: Railway Incident Report — May 19, 2026 · The Register