La nube tampoco es infalible. Una importante interrupción en la infraestructura de Google Cloud en Londres provocó este martes problemas en plataformas financieras, aplicaciones y servicios digitales, dejando a numerosos usuarios sin acceso normal a operaciones esenciales.
Uno de los casos más destacados fue Revolut, cuyos clientes experimentaron dificultades para pagar con tarjetas, realizar transferencias, retirar dinero de cajeros automáticos y acceder a sus cuentas.
El incidente volvió a poner sobre la mesa una pregunta importante: ¿qué sucede cuando una infraestructura de la que dependen tantos servicios deja de funcionar?
¿Qué provocó la caída de Google Cloud?
Google confirmó que el problema comenzó el 20 de octubre de 2026, a las 06:08 UTC, y afectó inicialmente a la zona de disponibilidad europe-west2-b, ubicada en Londres.
La compañía identificó un incidente eléctrico que provocó la indisponibilidad de servicios en esa zona y generó errores de red e interrupciones en distintos productos de la región europe-west2.
Entre las tecnologías afectadas figuraron Google Kubernetes Engine, Cloud Run, Cloud SQL, Cloud Storage, Firestore y otros servicios utilizados por desarrolladores y empresas.
Tras casi ocho horas, Google dio por cerrado el incidente general, aunque advirtió que un pequeño número de clientes todavía podía experimentar dificultades.
Revolut y otros bancos también sufrieron las consecuencias
El impacto fue especialmente visible en el sector financiero.
Revolut reconoció problemas en múltiples operaciones y aseguró que el dinero y los datos de sus clientes permanecían seguros.
También se registraron interrupciones en servicios de entidades como Lloyds, Halifax y HSBC en Reino Unido.
La situación demostró que una falla localizada en un centro de datos puede tener consecuencias mucho más amplias cuando aplicaciones y sistemas financieros dependen de esa infraestructura.
¿Por qué una sola falla puede afectar a tantas empresas?
Muchas aplicaciones modernas funcionan mediante servicios distribuidos en la nube.
Sus bases de datos, API, sistemas de autenticación, servidores y procesos internos pueden depender de una misma región o de componentes compartidos.
Cuando uno de esos elementos esenciales deja de responder, el problema puede propagarse hacia otras funcionalidades.
Por ejemplo, una aplicación bancaria podría mantener su interfaz disponible, pero no permitir pagos si el sistema encargado de procesar las transacciones se encuentra fuera de servicio.
Estar alojado en la nube no garantiza automáticamente una disponibilidad del 100 %.
¿Cómo pueden evitar los desarrolladores que sus aplicaciones sufran este problema?
Este incidente deja varias lecciones para quienes construyen aplicaciones y plataformas digitales.
-
Arquitectura multirregión: distribuir servicios críticos en distintas regiones para reducir la dependencia de una sola ubicación.
-
Replicación de datos: mantener copias consistentes de la información en infraestructura independiente.
-
Failover automático: permitir que el sistema utilice recursos alternativos cuando detecta una interrupción.
-
Monitoreo y alertas: identificar rápidamente errores de conectividad, disponibilidad y rendimiento.
-
Pruebas de recuperación: simular fallos reales para comprobar que los mecanismos de contingencia funcionan correctamente.
Sin embargo, implementar estas medidas no es sencillo ni gratuito. Requiere inversión, mantenimiento, planificación y una correcta estrategia de recuperación.
Además, una arquitectura multirregión mal diseñada tampoco garantiza que el servicio permanezca operativo.
La lección que deja esta caída de Google Cloud
La interrupción de Londres demuestra que incluso las grandes plataformas tecnológicas pueden experimentar fallos de infraestructura.
Para las empresas, la disponibilidad no debe depender exclusivamente de las garantías ofrecidas por un proveedor.
Y para los desarrolladores, este episodio recuerda la importancia de diseñar sistemas capaces de recuperarse cuando algo falla.
La verdadera resiliencia no consiste en creer que los servidores nunca fallarán, sino en preparar nuestras aplicaciones para cuando inevitablemente ocurra.
Porque hoy fue Google Cloud en Londres. Mañana podría ser cualquier otra infraestructura de la que dependa nuestra aplicación.
