Cloudflare (2026): quando uma dependência single-AZ derruba um cluster 'HA'

Em 20 de fevereiro de 2026, a Cloudflare registrou uma falha na zona interna PDX-04, localizada em Portland, Oregon. PDX-04 é um dos datacenters internos que a Cloudflare opera para suportar sua infraestrutura de controle, distinto da rede global de edge que entrega tráfego HTTP, DNS e segurança para seus clientes.

A falha em si na zona não foi o problema central. O problema foi o que estava exclusivamente nessa zona: instâncias de Kafka responsáveis por ingestão de eventos de log, e instâncias de ClickHouse responsáveis por armazenar e servir consultas de analytics. Esses dois sistemas não tinham réplicas em outras zonas. Eram, na prática, single-AZ, apesar de fazerem parte de uma arquitetura que, no papel, era descrita como de alta disponibilidade.

Quando PDX-04 ficou indisponível, os serviços do plano de controle que dependiam de Kafka para publicar eventos e de ClickHouse para consultar dados de analytics simplesmente pararam de funcionar ou entraram em estado de erro. O plano de dados global da Cloudflare, o que processa o tráfego real dos clientes, continuou operando normalmente, pois é arquitetado de forma independente. Mas a capacidade de observar, controlar e analisar esse tráfego ficou comprometida.

O que torna esse incidente particularmente interessante do ponto de vista arquitetural é a natureza da dependência: ela era implícita. Os serviços do cluster HA não tinham, aparentemente, uma documentação explícita de que dependiam de componentes single-AZ. O mapeamento de dependências não havia capturado essa relação. E os testes de resiliência, se existiam, não haviam simulado a perda de PDX-04 de forma isolada.

Existe uma distinção crítica entre HA declarado e HA verificado. HA declarado é o que aparece na documentação de arquitetura: "nosso cluster tem N nós em M zonas". HA verificado é o que você obtém quando mapeia todas as dependências transitivas de cada serviço e confirma que cada uma delas também satisfaz o mesmo SLA de disponibilidade.

No caso da Cloudflare, o cluster de plano de controle satisfazia HA declarado. Mas Kafka e ClickHouse, que são dependências de suporte críticas, não opcionais, eram single-AZ. Isso cria o que eu chamo de HA com asterisco: o sistema sobrevive a falhas de nós individuais de computação, mas colapsa completamente se o serviço de dados subjacente falhar.

Esse padrão é surpreendentemente comum. Ele aparece quando:

1. Serviços de infraestrutura crescem organicamente: Kafka e ClickHouse foram provavelmente provisionados inicialmente como serviços de suporte menores, sem o mesmo rigor de resiliência aplicado aos serviços de produção principais. Com o tempo, a dependência cresceu, mas a classificação de criticidade não foi revisada.

1. O mapeamento de dependências não é mantido: Em sistemas que evoluem rapidamente, é comum que o grafo de dependências real divirja do documentado. Sem ferramentas de descoberta automática de dependências ou revisões periódicas estruturadas, essas lacunas se acumulam silenciosamente.

1. Testes de resiliência são incompletos: Chaos engineering e game days tendem a testar falhas nos serviços que já sabemos que são críticos. Dependências de suporte, como pipelines de observabilidade, são frequentemente excluídas por serem consideradas "não críticas para o negócio". Mas quando o plano de controle falha, a distinção entre crítico e não-crítico colapsa.

Há também uma dimensão de acoplamento entre plano de dados e plano de observabilidade que merece atenção. Neste incidente, o tráfego global da Cloudflare continuou fluindo, o plano de dados estava saudável. Mas a capacidade de observar, diagnosticar e potencialmente intervir nesse tráfego ficou comprometida. Em cenários de segurança ou de resposta a incidentes, essa perda de visibilidade pode transformar um problema gerenciável em um problema crítico.

O post-mortem da Cloudflare identifica ações corretivas em várias dimensões. Analiso cada uma delas com a perspectiva de quem já implementou sistemas similares:

1. Replicação multi-zona para Kafka e ClickHouse

A ação mais direta: garantir que os brokers Kafka e os nós ClickHouse existam em múltiplas zonas, com replicação configurada entre elas. Para Kafka, isso significa configurar min.insync.replicas e replication.factor de forma que a perda de uma zona não resulte em perda de dados nem em indisponibilidade de escrita. Para ClickHouse, significa configurar réplicas em zonas distintas com replicação síncrona ou assíncrona dependendo do SLA de consistência aceitável.

O desafio prático aqui é custo e latência. ClickHouse com replicação síncrona entre zonas introduz latência de escrita. A decisão de replicação assíncrona versus síncrona é um trade-off real que precisa ser documentado explicitamente, não assumido.

2. Auditoria e mapeamento de dependências

Identificar todos os serviços que dependem de componentes single-AZ e classificá-los por criticidade. Isso soa simples, mas em organizações de escala da Cloudflare, o grafo de dependências pode ter centenas de serviços. A abordagem prática que recomendo é uma combinação de:

• Rastreamento distribuído (como Jaeger ou Zipkin) para descoberta automática de dependências em runtime
• Revisões estruturadas de arquitetura antes de qualquer promoção de serviço para produção
• Um registro de dependências mantido como código (dependency manifests), auditado periodicamente

3. Isolamento entre plano de dados e plano de observabilidade

Esta é a lição mais sofisticada do incidente. O plano de observabilidade, logs, métricas, analytics, não deve compartilhar dependências de infraestrutura com o plano de dados que ele monitora. Se o pipeline de logs usa o mesmo Kafka que o plano de controle, uma falha nesse Kafka cega simultaneamente o sistema operacional e o sistema de diagnóstico.

A solução arquitetural é tratar o plano de observabilidade como um sistema de criticidade igual ou superior ao plano de dados, com seu próprio conjunto de dependências isoladas. Em AWS, por exemplo, isso significa pipelines de logs em contas separadas, com IAM cross-account estritamente controlado e sem dependências compartilhadas de infraestrutura.

4. Chaos engineering com escopo ampliado

Incluir explicitamente dependências de suporte: Kafka, ClickHouse, sistemas de cache, pipelines de ETL, nos cenários de chaos engineering. A pergunta que deve guiar o design dos experimentos não é "o que acontece se este serviço falhar?" mas "o que acontece se qualquer componente do qual este serviço depende, direta ou transitivamente, falhar?"