# Cloudflare (2026): quando uma dependência single-AZ derruba um cluster 'HA' Em 20 de fevereiro de 2026, a Cloudflare sofreu um outage no plano de controle e em analytics porque Kafka e ClickHouse — serviços críticos de ingestão e consulta de dados — existiam apenas na zona PDX-04, enquanto o cluster declarado como de alta disponibilidade dependia deles de forma implícita. O incidente expõe um padrão recorrente em sistemas distribuídos: a ilusão de HA criada por redundância parcial que não cobre todas as dependências da cadeia. - URL: https://fernando.moretes.com/studies/cloudflare-single-az-2026 - Markdown: https://fernando.moretes.com/studies/cloudflare-single-az-2026/study.md?lang=pt - Type: Post-mortem - Company: Cloudflare - Domain: Dados/Resiliência - Date: 2026-02-20 - Tags: postmortem, cloudflare, single-az, kafka, clickhouse, resiliência, observabilidade, dependências ocultas - Reading time: 9 min --- ## Fatos do Incidente - **Empresa:** Cloudflare - **Data:** 20 de fevereiro de 2026 - **Duração total:** Várias horas (degradação parcial estendida) - **Sistemas afetados:** Plano de controle, pipeline de logs, analytics (ClickHouse), ingestão de eventos (Kafka) - **Zona de falha:** PDX-04 (Portland, Oregon — datacenter interno Cloudflare) - **Stack envolvido:** Kafka, ClickHouse, serviços internos de plano de controle, pipelines de observabilidade - **Impacto no tráfego de rede:** Tráfego de rede global da Cloudflare não foi afetado — plano de dados permaneceu operacional - **Causa raiz:** Dependência implícita de serviços single-AZ (Kafka e ClickHouse em PDX-04) por cluster declarado como HA - **Fonte pública:** Post-mortem oficial publicado no blog da Cloudflare Alta disponibilidade não é uma propriedade que se declara — é uma propriedade que se prova em cada elo da cadeia de dependências. O outage da Cloudflare em fevereiro de 2026 é um caso didático preciso sobre como um cluster multi-nó, operado com todas as boas intenções de redundância, pode ter seu SLA completamente anulado por um único serviço de suporte que nunca foi replicado entre zonas. ## O que aconteceu 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. ## Linha do Tempo 1. **T+0 — Falha em PDX-04** — A zona interna PDX-04 torna-se indisponível. As causas exatas da falha da zona são internas, mas o efeito cascata começa imediatamente nos serviços que dependem dela. 2. **T+minutos — Kafka e ClickHouse ficam inacessíveis** — Os brokers Kafka e os nós ClickHouse, todos residentes em PDX-04, param de responder. Não há failover automático porque não há réplicas em outras zonas para assumir. 3. **T+minutos — Serviços do plano de controle começam a falhar** — Serviços do cluster HA que publicam logs via Kafka e consultam analytics via ClickHouse começam a retornar erros ou ficam presos em timeouts. O plano de controle — responsável por configurações, dashboards e observabilidade — degrada. 4. **T+minutos a horas — Detecção e triagem** — As equipes identificam que o plano de dados global está saudável. A investigação se concentra nos serviços de controle e analytics. A dependência de PDX-04 é identificada como o elo comum de falha. 5. **T+horas — Restauração de PDX-04 ou roteamento alternativo** — A zona é recuperada ou os serviços são roteados para contornar a dependência. Os pipelines de Kafka e ClickHouse retomam operação. O plano de controle e analytics voltam ao estado normal. 6. **Pós-incidente — Publicação do post-mortem** — A Cloudflare publica análise blameless detalhando a causa raiz, o impacto e as ações corretivas planejadas, incluindo replicação multi-zona para Kafka e ClickHouse e revisão do mapeamento de dependências. ## Fluxo de Falha: Dependência Single-AZ por Trás de um Cluster HA O diagrama mostra como os serviços do plano de controle, distribuídos em múltiplas zonas (aparência de HA), dependiam de Kafka e ClickHouse existentes apenas em PDX-04. A falha da zona única propagou-se para cima na cadeia, derrubando observabilidade e analytics apesar da redundância parcial. ### 🌐 Global Edge (não afetado / unaffected) - Cloudflare Edge Data Plane (edge) ### 🏢 Plano de Controle HA (multi-zona / multi-zone) - Control Plane Zona A (compute) - Control Plane Zona B (compute) - Control Plane PDX-04 (compute) ### 💥 PDX-04 — Single-AZ (ponto de falha / failure point) - Kafka Log Ingestion ⚠️ single-AZ (messaging) - ClickHouse Analytics Store ⚠️ single-AZ (data) - PDX-04 Zone Infra ❌ FALHOU (network) ### 👤 Consumidores / Consumers - Dashboards & Analytics UI (frontend) - Log Pipeline Consumers (compute) ### Fluxos - edge -> cp_a: eventos/logs - edge -> cp_b: eventos/logs - edge -> cp_pdx04: eventos/logs - cp_a -> kafka: publica eventos - cp_b -> kafka: publica eventos - cp_pdx04 -> kafka: publica eventos - cp_a -> clickhouse: consulta analytics - cp_b -> clickhouse: consulta analytics - kafka -> log_consumer: consome logs - clickhouse -> dashboard: serve queries - pdx04_infra -> kafka: ❌ zona falhou - pdx04_infra -> clickhouse: ❌ zona falhou > **Causa Raiz: A Ilusão de HA por Dependência Implícita Single-AZ:** O cluster de plano de controle era multi-zona na camada de computação, mas dependia de Kafka e ClickHouse que existiam apenas em PDX-04. Essa dependência era implícita — não documentada explicitamente no mapeamento de dependências do sistema. O resultado: a garantia de HA do cluster era falsa. Qualquer falha em PDX-04 colapsava toda a capacidade de ingestão de logs e analytics, independentemente de quantos nós de computação estivessem saudáveis em outras zonas. HA declarado sem HA verificado nas dependências de suporte é apenas disponibilidade parcial com um nome enganoso. ## O Problema Estrutural: Dependências Ocultas e o Limite do HA Declarado 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. 2. **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. 3. **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. ## Remediação e Ações Corretivas 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?" ## Lições Técnicas - **HA é uma propriedade transitiva**: um cluster é tão disponível quanto sua dependência menos disponível. Declarar HA na camada de computação sem verificar as dependências de dados e mensageria é uma garantia falsa. - **Dependências implícitas são dívida técnica de resiliência**: se uma dependência não está documentada no mapeamento de criticidade do sistema, ela é uma bomba-relógio. O mapeamento de dependências deve ser tratado como artefato de produção, não como documentação opcional. - **Isole o plano de observabilidade do plano de dados**: pipelines de logs e analytics não devem compartilhar infraestrutura com os sistemas que monitoram. Perder observabilidade durante um incidente é o pior momento para ficar cego. - **Kafka e ClickHouse em produção exigem configuração explícita de multi-AZ**: não é suficiente provisionar múltiplos nós — é preciso configurar replication factor, min.insync.replicas (Kafka) e réplicas entre zonas (ClickHouse) com trade-offs de latência e custo documentados. - **Chaos engineering deve cobrir dependências de suporte**: testes de resiliência que cobrem apenas os serviços primários deixam as dependências de infraestrutura — mensageria, analytics, cache — como pontos cegos de falha. - **O plano de dados sobreviver não significa que o incidente é menor**: quando o plano de controle e observabilidade falham, a capacidade de responder a incidentes de segurança ou operacionais fica severamente comprometida, mesmo que o tráfego continue fluindo. > **Minha Perspectiva: O Problema do HA com Asterisco:** Já vi esse padrão em sistemas financeiros, em plataformas de e-commerce e agora na Cloudflare. O mecanismo é sempre o mesmo: um serviço ganha o rótulo de "alta disponibilidade" porque a camada de computação foi corretamente replicada, mas ninguém auditou as dependências de suporte com o mesmo rigor. O que eu faria diferente? Primeiro, trataria o mapeamento de dependências como um artefato de produção com dono definido e revisão obrigatória em cada release significativo. Não como documentação — como um contrato de SLA interno. Segundo, aplicaria o princípio de que **qualquer serviço que alimenta o plano de observabilidade deve ter resiliência igual ou superior ao serviço que observa**. Isso parece óbvio dito assim, mas na prática é frequentemente ignorado porque pipelines de logs são vistos como "infraestrutura de suporte", não como componentes críticos. Terceiro — e isso é o que mais importa — eu separaria explicitamente o budget de caos: metade dos experimentos de chaos engineering em dependências de suporte (Kafka, ClickHouse, Redis, pipelines de ETL), não apenas nos serviços de negócio. A maioria das organizações faz o inverso. O incidente da Cloudflare é blameless no sentido correto: não é falha de uma pessoa, é falha de um processo de verificação de resiliência que não cobria dependências transitivas. A correção é sistêmica, não individual. ## Veredicto: HA Verificado, Não Declarado O outage da Cloudflare de fevereiro de 2026 é um caso de manual sobre como a ilusão de alta disponibilidade se forma e se desfaz. O sistema tinha redundância real na camada de computação. Mas Kafka e ClickHouse — os serviços que davam sentido a essa computação, ao armazenar e servir logs e analytics — existiam em uma única zona. Quando essa zona falhou, a redundância de computação tornou-se irrelevante. A lição central não é técnica no sentido estreito — não é sobre configurar `replication.factor=3` no Kafka, embora isso seja necessário. A lição é de processo e cultura: **a garantia de disponibilidade de um sistema deve ser verificada em todas as suas dependências transitivas, não apenas nos componentes que aparecem no diagrama de arquitetura principal**. Isso exige três coisas que a maioria das organizações não faz sistematicamente: (1) mapeamento de dependências mantido como artefato vivo, não documentação estática; (2) testes de resiliência que incluem dependências de suporte com o mesmo rigor dos serviços primários; (3) isolamento explícito entre o plano de dados e o plano de observabilidade, para que uma falha operacional não cegue simultaneamente o sistema e seu diagnóstico. A Cloudflare merece crédito pela transparência do post-mortem. Esse nível de abertura sobre falhas internas é raro e valioso para a comunidade de engenharia. O incidente em si é corrigível — e as ações descritas no post-mortem são as corretas. O que importa agora é que o processo de verificação de resiliência seja institucionalizado, não apenas que esses dois serviços específicos sejam replicados. ## Referências - [Cloudflare — Post-mortem on the Control Plane and Analytics Outage](https://blog.cloudflare.com/post-mortem-on-cloudflare-control-plane-and-analytics-outage/) ## Fontes do caso - [Cloudflare — Post-mortem on the Control Plane and Analytics Outage](https://blog.cloudflare.com/post-mortem-on-cloudflare-control-plane-and-analytics-outage/)