Caiu uma zona do Google Cloud. Caíram bancos inteiros

Na manhã de 20 de outubro de 2026, uma falha de energia num único datacenter do Google em Londres tirou do ar o app e os cartões do Revolut, o internet banking do Halifax, as transmissões de audiências dos tribunais britânicos e pedaços do Spotify e da DPD. O Google descreveu o problema numa frase: um "power event" na zona europe-west2-b. Uma zona. A arquitetura de nuvem existe justamente pra que a queda de uma zona seja um não-evento. Quando ela vira manchete, a pergunta útil não é "por que o Google caiu" — é "por que tanta coisa dependia de um prédio só".

O que de fato aconteceu

Os fatos confirmados até agora são poucos, e vale separá-los da especulação:

• O status do Google Cloud abriu um incidente na região europe-west2 (Londres) com 28 produtos afetados, de AlloyDB a Apigee e BigQuery.
• O Google atribuiu a causa a um evento de energia na zona europe-west2-b e, por volta do meio-dia no horário do Reino Unido, disse que ele estava mitigado.
• O Revolut relatou falhas em pagamentos com cartão, transferências, saques e login, e afirmou que "o dinheiro e os dados dos clientes estão seguros". O Halifax confirmou problemas no app e no online banking.
• O serviço de tribunais britânico perdeu a plataforma de vídeo usada em audiências remotas, segundo a ABC.

O que não se sabe ainda: por que cada uma dessas empresas não absorveu a perda de uma zona. O postmortem do Google vai explicar a parte dele. A parte de cada cliente provavelmente nunca vai ser pública.

Zona, região e a promessa que ninguém lê

Nos grandes provedores de nuvem, uma região é uma área geográfica (Londres) e uma zona é um conjunto isolado de datacenters dentro dela, com energia, refrigeração e rede próprias. Uma região típica do Google tem três zonas. A promessa é simples: zonas falham de forma independente, então quem roda em mais de uma sobrevive à queda de qualquer uma.

O detalhe que a cobertura não explica é que essa proteção não vem por padrão. Ela depende de como cada peça foi contratada:

Um sistema é tão resiliente quanto a peça mais zonal que ele tem no caminho crítico. Basta um banco de dados de sessão, um serviço de autenticação ou um fornecedor terceirizado rodando numa zona só pra transformar uma falha "contida" numa queda total.

Por que "regional" nem sempre segura

Mesmo quem fez a lição de casa pode cair, e é aqui que mora o mecanismo que interessa:

1. O failover é uma onda, não um interruptor. Quando uma zona some, todo o tráfego dela corre pras outras duas ao mesmo tempo. Se as zonas restantes não tinham folga de capacidade, elas engasgam — e o que era perda de um terço vira perda de tudo.
2. Dependência escondida. Um serviço gerenciado pode ser regional no dado e depender de componentes que não são. O incidente de hoje listou 28 produtos degradados na região, não só na zona que perdeu energia.
3. Failover que nunca foi testado é hipótese. Replicar dado é a parte fácil. Promover a réplica, reconectar as aplicações e drenar filas sem duplicar uma transferência bancária é a parte que só se descobre quebrada no dia.

Nenhum desses três é um defeito exótico. São as consequências normais de uma arquitetura que foi desenhada no diagrama e nunca foi desligada de propósito.

A parte que custa dinheiro

Redundância é uma decisão de orçamento disfarçada de decisão técnica. Rodar em três zonas custa mais em infraestrutura e, principalmente, em engenharia: a aplicação precisa ser stateless onde der, o banco precisa tolerar a troca de primário, e alguém precisa ensaiar a falha.

A conta do outro lado é o que aconteceu hoje: horas de pagamento recusado, clientes sem acesso ao próprio dinheiro, uma marca citada ao lado da palavra "queda" em todas as manchetes. Para um banco, isso é um evento regulatório. Para uma startup, pode ser o dia em que o maior cliente decide não renovar.

O erro mais comum que a gente vê não é escolher pouca redundância. É não saber que escolheu. A configuração zonal foi o padrão do primeiro deploy, ninguém revisitou, e o produto cresceu em cima dela.

O que a gente faria na segunda-feira

Se o seu produto roda em nuvem pública, este é o checklist que vale uma tarde:

1. Mapeie o caminho crítico. Login, pagamento, a tela principal. Para cada componente nesse caminho, anote: zonal, regional ou multirregional?
2. Ache o elo zonal. Quase sempre existe um — um Redis, um worker, um banco de réplica única. Decida conscientemente se ele fica assim.
3. Pergunte aos fornecedores. O provedor de autenticação, o gateway de pagamento, o serviço de e-mail: onde eles rodam e o que acontece se a zona deles cair?
4. Ensaie a queda. Desligue uma zona em staging e veja o que acontece. Um failover nunca testado não conta como redundância.
5. Desenhe o modo degradado. Se o pagamento cair, o app ainda mostra o saldo? Uma mensagem honesta na tela vale mais que um spinner infinito.

É a mesma disciplina que a gente aplica ao levar produto pra produção: a distância entre funcionar na demo e aguentar o dia ruim. Em eventos ao vivo, como no Ultimate Drift, a gente parte do princípio de que a peça vai cair no pior minuto possível — porque o pior minuto é exatamente quando todo mundo está olhando.

Principais conclusões

• A queda de 20 de outubro começou numa única zona do Google Cloud em Londres, por falha de energia, e derrubou bancos e serviços públicos.
• Na nuvem, redundância entre zonas não vem por padrão: recursos zonais caem com a zona.
• Um sistema é tão resiliente quanto o componente mais zonal do seu caminho crítico, incluindo fornecedores.
• Mesmo arquiteturas regionais caem quando o failover nunca foi testado ou as zonas restantes não têm folga.
• Quanto pagar por redundância é decisão de negócio. O problema é tomar essa decisão sem saber.

FAQ

O que causou a queda do Google Cloud em 20 de outubro de 2026? Segundo o Google, um evento de energia na zona europe-west2-b, em Londres. O incidente afetou 28 produtos na região europe-west2.

Qual a diferença entre zona e região na nuvem? Uma região é uma área geográfica; uma zona é um conjunto isolado de datacenters dentro dela, com energia e rede próprias. Rodar em várias zonas protege contra a falha de uma; rodar em várias regiões protege contra a falha da região inteira.

Migrar de provedor resolveria? Não por si só. AWS e Azure usam o mesmo modelo de zonas e regiões, com a mesma regra: a redundância é contratada e configurada por você.

Multinuvem é a resposta? Raramente para uma startup. O custo de operar dois provedores costuma superar o risco que ele elimina. Multizona bem testada resolve a maior parte do problema por uma fração do custo.

Como saber se meu produto está exposto? Liste os componentes do caminho crítico e verifique onde cada um roda. Se algum for zonal ou você não souber responder, essa é a exposição.