Cuando la redundancia no alcanza: el apagón ferroviario y las dependencias del control plane
El problema de la redundancia que nadie ve venir
Cuando llevas tiempo trabajando con infraestructuras en la nube, es fácil caer en la idea de que distribuir todo entre AWS, Google Cloud y servidores propios te protege de cualquier problema. Parece lógico. Debería funcionar.
Railway, una plataforma moderna de despliegues, apostó por esta estrategia. Sus aplicaciones se ejecutaban en Google Cloud, AWS y Railway Metal. Por cualquier métrica tradicional, tenían la redundancia resuelta.
Pero el 19 de mayo de 2026, todo se vino abajo. No por un desastre natural ni por un fallo técnico grave. Google Cloud suspendió automáticamente la cuenta de producción de Railway sin previo aviso. Ocho horas después, tras una noche de trabajo intenso, volvieron a estar operativos.
Lo más sorprendente: las aplicaciones seguían funcionando correctamente todo el tiempo.
El punto débil que nadie controla
El tráfico que llega a las aplicaciones de Railway no va directamente a ellas. Pasa primero por proxies en el borde de la red que deciden hacia dónde enviarlo. Estos proxies necesitan saber dónde está cada aplicación en cada momento.
Esa información vive en el control plane: una especie de base de datos que indica qué carga de trabajo está en qué sitio. Y el control plane de Railway estaba alojado completamente en Google Cloud.
Cuando se suspendió la cuenta, el control plane dejó de estar disponible. Los proxies siguieron funcionando durante un tiempo gracias a su caché de rutas, que se mantuvo válida unos 35 minutos. Las aplicaciones seguían recibiendo tráfico.
Pero cuando la caché se agotó, los proxies ya no sabían dónde enviar las peticiones. Todas las solicitudes devolvían un 404, sin importar que las aplicaciones estuviesen sanas y funcionando en AWS o Railway Metal.
Una cadena de problemas que se complica
Asustados por la cantidad de errores y reintentos, GitHub activó su protección contra ataques en los endpoints de OAuth de Railway. No era un problema de GitHub, sino una medida de seguridad normal.
La consecuencia directa: los usuarios ya no podían iniciar sesión. Los despliegues se bloquearon. Incluso cuando el control plane se recuperó, este segundo problema seguía impidiendo el acceso normal.
La diferencia entre distribuir y realmente controlar
Esta experiencia revela una distinción importante: tener workloads distribuidos no es lo mismo que tener un control distribuido.
Railway lo había conseguido en parte. Sus aplicaciones estaban en varios clouds y hardware propio. Pero el control plane, que es el que steuert la información de dónde va el tráfico, estaba en un solo lugar. Una sola acción automática de Google Cloud terminó afectando toda la infraestructura.
这