Cayó una zona de Google Cloud. Cayeron bancos enteros

La mañana del 20 de octubre de 2026, un fallo eléctrico en un único datacenter de Google en Londres dejó sin servicio la app y las tarjetas de Revolut, la banca online de Halifax, las transmisiones de audiencias de los tribunales británicos y partes de Spotify y DPD. Google lo describió en una línea: un "power event" en la zona europe-west2-b. Una zona. La arquitectura en la nube existe precisamente para que perder una zona no sea noticia. Cuando se vuelve titular, la pregunta útil no es "por qué cayó Google", sino "por qué tanto dependía de un solo edificio".

Qué pasó realmente

Los hechos confirmados son pocos, y conviene separarlos de la especulación:

• La página de estado de Google Cloud abrió un incidente en la región europe-west2 (Londres) con 28 productos afectados, desde AlloyDB hasta Apigee y BigQuery.
• Google lo atribuyó a un evento eléctrico en la zona europe-west2-b y dijo que estaba mitigado hacia el mediodía, hora del Reino Unido.
• Revolut reportó fallos en pagos con tarjeta, transferencias, retiros e inicio de sesión, y afirmó que "el dinero y los datos de los clientes están seguros". Halifax confirmó problemas en su app y banca online.
• El servicio de tribunales británico perdió la plataforma de video usada en audiencias remotas, según ABC.

Lo que no se sabe todavía: por qué cada una de estas empresas no absorbió la pérdida de una zona. El postmortem de Google explicará su parte. La de cada cliente probablemente nunca será pública.

Zonas, regiones y la promesa que nadie lee

En los grandes proveedores de nube, una región es un área geográfica (Londres) y una zona es un conjunto aislado de datacenters dentro de ella, con energía, refrigeración y red propias. Una región típica de Google tiene tres zonas. La promesa es simple: las zonas fallan de forma independiente, así que lo que corre en más de una sobrevive a la caída de cualquiera.

El detalle que la cobertura no explica es que esta protección no viene por defecto. Depende de cómo se contrató cada pieza:

Un sistema es tan resiliente como la pieza más zonal de su ruta crítica. Basta un almacén de sesiones, un servicio de autenticación o un proveedor externo en una sola zona para convertir un fallo "contenido" en una caída total.

Por qué "regional" no siempre aguanta

Incluso quien hizo la tarea puede caer, y aquí está el mecanismo que importa:

1. El failover es una ola, no un interruptor. Cuando una zona desaparece, todo su tráfico corre a las otras dos a la vez. Si las zonas restantes no tenían capacidad de sobra, se ahogan, y perder un tercio se convierte en perderlo todo.
2. Dependencias ocultas. Un servicio gestionado puede ser regional en los datos y depender de componentes que no lo son. El incidente de hoy listó 28 productos degradados en la región, no solo en la zona que perdió energía.
3. Un failover nunca probado es una hipótesis. Replicar datos es lo fácil. Promover la réplica, reconectar las apps y vaciar colas sin duplicar una transferencia bancaria es lo que solo se descubre roto ese día.

Ninguno de estos tres es exótico. Son las consecuencias normales de una arquitectura dibujada en un diagrama y nunca apagada a propósito.

La parte que cuesta dinero

La redundancia es una decisión de presupuesto disfrazada de decisión técnica. Correr en tres zonas cuesta más en infraestructura y, sobre todo, en ingeniería: la app debe ser stateless donde se pueda, la base de datos debe tolerar el cambio de primario y alguien tiene que ensayar el fallo.

La factura del otro lado es lo que pasó hoy: horas de pagos rechazados, clientes sin acceso a su propio dinero, una marca impresa junto a la palabra "caída" en todos los titulares. Para un banco, es un evento regulatorio. Para una startup, puede ser el día en que el mayor cliente decide no renovar.

El error más común que vemos no es elegir poca redundancia. Es no saber que se eligió. Lo zonal fue el valor por defecto del primer deploy, nadie lo revisó y el producto creció encima.

Lo que haríamos el lunes

Si tu producto corre en nube pública, este checklist vale una tarde:

1. Mapea la ruta crítica. Login, pago, la pantalla principal. Para cada componente, anota: ¿zonal, regional o multirregional?
2. Encuentra el eslabón zonal. Casi siempre hay uno: un Redis, un worker, una base de datos de réplica única. Decide a conciencia si se queda así.
3. Pregunta a tus proveedores. Autenticación, pasarela de pago, servicio de email: ¿dónde corren y qué pasa si cae su zona?
4. Ensaya la caída. Apaga una zona en staging y observa. Un failover nunca probado no cuenta como redundancia.
5. Diseña el modo degradado. Si el pago cae, ¿la app sigue mostrando el saldo? Un mensaje honesto vale más que un spinner infinito.

Es la misma disciplina que aplicamos al llevar productos a producción: la distancia entre funcionar en la demo y aguantar el día malo. En eventos en vivo, como en Ultimate Drift, partimos de que la pieza va a caer en el peor minuto posible, porque el peor minuto es justo cuando todos están mirando.

Conclusiones clave

• La caída del 20 de octubre empezó en una sola zona de Google Cloud en Londres, por un fallo eléctrico, y tumbó bancos y servicios públicos.
• En la nube, la redundancia entre zonas no viene por defecto: los recursos zonales caen con su zona.
• Un sistema es tan resiliente como el componente más zonal de su ruta crítica, proveedores incluidos.
• Incluso las arquitecturas regionales caen cuando el failover nunca se probó o las zonas restantes no tienen holgura.
• Cuánto pagar por redundancia es una decisión de negocio. El problema es tomarla sin saberlo.

FAQ

¿Qué causó la caída de Google Cloud el 20 de octubre de 2026? Según Google, un evento eléctrico en la zona europe-west2-b, en Londres. El incidente afectó a 28 productos en la región europe-west2.

¿Cuál es la diferencia entre zona y región? Una región es un área geográfica; una zona es un conjunto aislado de datacenters dentro de ella, con energía y red propias. Varias zonas protegen contra la caída de una; varias regiones protegen contra la caída de toda la región.

¿Cambiar de proveedor lo resolvería? No por sí solo. AWS y Azure usan el mismo modelo de zonas y regiones, con la misma regla: la redundancia la contratas y configuras tú.

¿Multinube es la respuesta? Rara vez para una startup. El costo de operar dos proveedores suele superar el riesgo que elimina. Multizona bien probada resuelve la mayor parte del problema por una fracción del costo.

¿Cómo sé si mi producto está expuesto? Lista los componentes de tu ruta crítica y verifica dónde corre cada uno. Si alguno es zonal, o no sabes responder, esa es tu exposición.