Como uma atualização de banco de dados pode paralisar 20% da internet global

11 de novembro de 2023 - Aviso de falha: Quando a Cloudflare fica offline, quem paga a conta da infraestrutura?

Às 6h20 (horário de Lisboa), cerca de 20% do tráfego global da internet caiu repentinamente. Uma atualização rotineira de permissões na base de dados desencadeou uma reação em cadeia que resultou na interrupção em larga escala dos serviços essenciais que suportam a internet moderna.

Não foi um ataque hacker, nem uma ameaça externa. A causa raiz foi uma simples configuração cujo tamanho dobrou, ultrapassando o limite padrão do sistema.

O desastre começou com uma consulta simples ao banco de dados

A cronologia do evento é clara e brutal:

UTC 11:05 — Cloudflare atualiza permissões no cluster de bancos de dados ClickHouse, com o objetivo de aumentar segurança e confiabilidade.

UTC 11:28 — A mudança se propaga ao ambiente de usuário, surgindo o primeiro registro de erro.

UTC 11:48 — A página de status oficial reconhece a falha.

UTC 17:06 — O serviço é totalmente restaurado, após mais de 5 horas de indisponibilidade.

A verdade técnica

O problema central foi uma omissão aparentemente simples: a consulta ao banco de dados responsável por gerar o arquivo de configuração do sistema de proteção contra robôs da Cloudflare não continha um filtro por “nome do banco de dados”.

Isso fez com que o sistema retornasse entradas duplicadas — uma do banco de dados padrão, outra do banco de dados de armazenamento de baixo nível, r0. Como resultado, o arquivo de configuração cresceu de cerca de 60 para mais de 200 características.

A Cloudflare tinha um limite codificado de 200 características na alocação de memória antecipada, considerado “muito acima do uso real atual” pelos engenheiros. Mas, quando a falha ocorreu, essa margem de segurança aparentemente confortável se quebrou instantaneamente.

O arquivo que excedeu o limite disparou uma falha no código Rust, que lançou um erro: “thread fl2_worker_thread panicked: called Result::unwrap() on an Err value”

O sistema de proteção contra bots é o núcleo do controle da rede da Cloudflare. Quando ele falha, o sistema de verificação de integridade que informa ao balanceador de carga “quais servidores estão operando normalmente” também deixa de funcionar.

De forma irônica, esse arquivo de configuração é recriado a cada 5 minutos. Assim, qualquer consulta feita após a atualização do cluster gera dados incorretos. O resultado é que a rede da Cloudflare fica oscilando entre “funcionando normalmente” e “falha”, alternando entre carregar o arquivo correto e o incorreto.

Esse ciclo de “interrupções repetidas” levou os engenheiros a acreditarem que estavam sob um ataque DDoS massivo. Pois erros internos normalmente não causam esse ciclo de recuperação e falha periódica.

No final, após a atualização de todos os nós do ClickHouse, cada arquivo gerado continha dados incorretos. Sem um sinal claro do sistema, o sistema de proteção entra em modo “conservador”, considerando a maioria dos servidores como “não confiáveis”. O tráfego da internet continua a chegar às bordas da rede da Cloudflare, mas não consegue ser roteado corretamente.

O momento de silêncio na rede global

Plataforma Web2 completamente inoperante

• X recebeu 9.706 relatórios de falhas
• ChatGPT parou de responder no meio de uma conversa
• Spotify interrompeu o streaming
• Uber e plataformas de delivery apresentaram falhas
• Jogadores foram desconectados forçadamente
• Até as máquinas de autoatendimento do McDonald’s exibiram telas de erro

Nenhuma área de criptomoedas escapou

As páginas de principais exchanges ficaram fora do ar, com usuários enfrentando telas de login e interfaces de negociação não carregando.

Os exploradores de blockchain (como Etherscan, Arbiscan) ficaram indisponíveis.

Plataformas de análise de dados (DeFiLlama) apresentaram erros intermitentes de servidor.

Fabricantes de carteiras físicas emitiram comunicados sobre queda na disponibilidade do serviço.

A única “exceção”: o próprio protocolo blockchain

Segundo relatos, as principais exchanges não apresentaram falhas na interface frontend, e as transações na blockchain continuam normalmente. A blockchain permanece operando normalmente, sem sinais de interrupção de consenso.

Isso revela uma contradição aguda: se a blockchain ainda está gerando blocos, mas ninguém consegue acessá-la, então as criptomoedas ainda estão “online”?

O papel da Cloudflare no tráfego global da internet

A Cloudflare não hospeda sites nem fornece servidores na nuvem. Sua função é atuar como “intermediária” — entre o usuário e a rede.

Dados principais:

• Atende a 24 milhões de sites
• Possui pontos de presença em 120 países e 330 cidades
• Processa cerca de 20% do tráfego global da internet
• Detém 82% do mercado de proteção contra DDoS
• Sua largura de banda total nos pontos de presença é de 449 Tbps

Quando essa “intermediação” falha, todos os serviços dependentes por trás dela também ficam “inacessíveis”.

O CEO da Cloudflare, Matthew Prince, afirmou em comunicado oficial: “Esta foi a falha mais grave desde 2019… Nos mais de 6 anos, nunca havíamos experimentado uma falha que impedisse a maior parte do tráfego essencial da internet de passar pela nossa rede.”

Quatro grandes falhas em 18 meses: por que a indústria ainda não mudou?

Julho de 2024 — Vulnerabilidade de atualização de segurança da CrowdStrike causa paralisação global de sistemas de TI (voos cancelados, hospitais atrasados, serviços financeiros congelados)

20 de outubro de 2025 — Falha na AWS dura 15 horas, interrupção do DynamoDB na região leste dos EUA, levando à queda de várias redes blockchain

29 de outubro de 2025 — Problemas de sincronização na configuração do Azure da Microsoft, interrupção do Microsoft 365 e Xbox Live

18 de novembro de 2025 — Falha na Cloudflare, afetando cerca de 20% do tráfego da internet global

Risco do modelo de contrato com um único fornecedor

A AWS controla cerca de 30% do mercado de infraestrutura em nuvem, a Microsoft Azure 20%, e o Google Cloud 13%. Essas três empresas sustentam mais de 60% da infraestrutura que suporta a internet moderna.

A indústria de criptomoedas deveria ser uma solução “descentralizada”, mas hoje depende desses fornecedores altamente centralizados.

Quando ocorre uma falha, a única “estratégia de recuperação” do setor é: esperar. Esperar a Cloudflare consertar, a AWS recuperar, a Azure aplicar patches.

A falsa promessa do “descentralizado”: protocolo não é igual a acesso descentralizado

O sonho que a indústria de criptomoedas vendia ao mundo era:

Finanças descentralizadas, moedas resistentes à censura, sistemas sem confiança, sem ponto único de falha, código é lei

Mas, em 18 de novembro, a realidade foi: uma falha matinal deixou a maior parte dos serviços de criptomoedas parados por horas.

Na prática: nenhuma falha foi reportada nos protocolos blockchain.

Na prática: interfaces de negociação caíram, browsers ficaram indisponíveis, plataformas de dados apresentaram erros 500.

Usuários não conseguem acessar a “descentralizada” blockchain que “possuem”. Os protocolos continuam operando normalmente — desde que você consiga “conectá-los”.

Por que o setor ainda escolhe “conveniência” ao invés de “princípios”?

Construir uma infraestrutura descentralizada própria significa: comprar hardware caro, garantir energia estável, manter banda dedicada, contratar especialistas em segurança, implementar redundância geográfica, criar sistemas de recuperação de desastres, monitorar 24/7.

Já usar Cloudflare é só: clicar, inserir dados do cartão, em poucos minutos estar operacional.

Startups buscam “entrada rápida no mercado”, investidores exigem “eficiência de capital” — todos optam por “conveniência”, não por “resistência a falhas”.

Até que a “conveniência” deixe de ser conveniente.

Por que as alternativas descentralizadas “não pegam”?

Armazenamento descentralizado (como Arweave), transmissão de arquivos distribuída (IPFS), computação descentralizada (Akash), hospedagem descentralizada (Filecoin) existem.

Porém, enfrentam problemas como:

• Desempenho inferior ao centralizado, latência perceptível pelo usuário
• Baixa adoção, processos complicados
• Custos muitas vezes superiores ao aluguel de infraestrutura dos três maiores provedores de nuvem

Construir uma infraestrutura verdadeiramente descentralizada é extremamente difícil, muito além do imaginável.

A maioria dos projetos apenas fala em “descentralização”, mas raramente implementa de fato. Optar por soluções centralizadas é sempre mais simples e barato — até ocorrer uma falha.

Novos desafios regulatórios

Três grandes falhas em 30 dias já despertaram atenção de órgãos reguladores:

• Essas empresas são “instituições de importância sistêmica”?
• Serviços de backbone da internet devem ser regulados como “serviços públicos”?
• Quais riscos surgem ao unir “grande demais para quebrar” com infraestrutura tecnológica?
• A Cloudflare, controlando 20% do tráfego global, configura um potencial monopólio?

O Departamento de Justiça dos EUA está promovendo a incorporação de credenciais de identidade em contratos inteligentes, exigindo KYC para toda interação DeFi. Quando a próxima falha na infraestrutura acontecer, os usuários perderão não só o acesso às transações — mas também a capacidade de “provar sua identidade” no sistema financeiro.

Uma falha de 3 horas hoje pode se transformar em “impossibilidade de passar na verificação humana” por 3 horas, só porque o serviço de verificação está operando na infraestrutura que caiu.

De “conveniência” a “inevitável”: quando será o ponto de virada?

18 de novembro, a indústria de criptomoedas não “falhou” — a blockchain funciona perfeitamente.

O verdadeiro “fracasso” é a ilusão coletiva do setor:

• Acreditar que é possível construir “aplicações imbatíveis” sobre “infraestrutura vulnerável”
• Acreditar que, com três empresas controlando “canais de acesso”, “resistência à censura” ainda faz sentido
• Acreditar que, com uma configuração da Cloudflare, milhões podem negociar — e “descentralização” ainda tem significado

A resistência a falhas na infraestrutura não deve ser um “extra”, mas uma “base fundamental” — sem ela, nada mais funciona.

A próxima falha já está sendo preparada — pode vir do AWS, do Azure, do Google Cloud, ou de uma segunda falha na Cloudflare. Pode acontecer no próximo mês, ou na próxima semana.

Optar por soluções centralizadas continua sendo mais barato, mais rápido, mais fácil — até que deixe de ser.

Quando a próxima configuração padrão da Cloudflare ativar uma vulnerabilidade oculta em um serviço crítico, veremos novamente o cenário familiar: telas de erro 500, negociações interrompidas, blockchain operando normalmente, mas inacessível, promessas de “melhorar na próxima vez” que nunca se cumprem.

Este é o dilema atual da indústria: nada muda, porque “conveniência” sempre vence “gestão de risco” — até o dia em que o preço da “conveniência” se torne tão alto que não possa mais ser ignorado.