Queda da Cloudflare em Junho/2025: Lições para Engenheiros de Software

É quinta-feira. Você pega sua caneca, abre o laptop e, de repente, metade da internet parece quebrada. Sites carregando lentamente, autenticação falhando e seus apps favoritos mostrando mensagens de erro misteriosas. Bem-vindo ao dia 12 de junho de 2025 — o dia em que a Cloudflare aprendeu uma dura lição sobre blast radius (raio de explosão).

Por 2 horas e 28 minutos, um dos provedores de infraestrutura mais confiáveis da internet experimentou uma reação em cadeia que se espalhou por milhões de aplicações ao redor do mundo. Esta não é apenas mais uma análise post-mortem; é uma história sobre como sistemas distribuídos modernos podem falhar de forma espetacular e, mais importante, como podemos construir sistemas melhores.

O Começo do Efeito Dominó

Tudo começou de forma inocente. Em algum lugar num data center, um provedor de armazenamento terceirizado — um que a maioria dos clientes da Cloudflare nunca tinha ouvido falar — começou a ter problemas. Não era culpa da Cloudflare, propriamente dita. Eles eram simplesmente um cliente, assim como você e eu.

Mas é aqui que a história fica interessante.

Esse provedor de armazenamento obscuro acabou sendo o backbone do serviço Workers Key-Value (KV) da Cloudflare — uma peça crítica de infraestrutura da qual milhares de aplicações dependiam para tudo, desde sessões de usuário até dados de configuração. Quando ele tropeçou, os dominós começaram a cair:

• 91% das requisições do Workers KV começaram a falhar
• 100% de falha nos logins Access
• 90%+ de taxa de erro no Stream
• Workers AI, Images, Turnstile e partes do Dashboard também foram afetados
• Milhares de aplicações dependentes ao redor do globo começaram a gerar erros
• Canais de suporte ao cliente se iluminaram como árvores de Natal

Caminho da Onda de Choque

O incidente da Cloudflare é uma aula magistral sobre como sistemas modernos falham. Não foi uma explosão dramática — foi mais como assistir um castelo de cartas cuidadosamente equilibrado desmoronar em câmera lenta.

A Linha do Tempo da Falha

Marco Zero (T+0 minutos): Um provedor de armazenamento terceirizado experimenta problemas internos. A maior parte do mundo ainda não percebe.

Impacto Primário (T+5 minutos): O serviço Workers KV da Cloudflare começa a dar timeout. Dashboards de alerta começam a mostrar avisos amarelos que logo se tornam vermelhos.

Impacto Secundário (T+15 minutos): Serviços que dependem do Workers KV — Access para autenticação corporativa, Stream para entrega de vídeo, Workers AI para inferência de machine learning — começam a falhar completamente. Estas não são degradações graciosas; são falhas duras.

Impacto Terciário (T+30 minutos): Aplicações de clientes que dependiam desses serviços começam a experimentar interrupções. Sites de e-commerce não conseguem autenticar usuários. Plataformas de streaming não conseguem entregar conteúdo. Recursos alimentados por IA simplesmente desaparecem.

Impacto no Ecossistema (T+60 minutos): O blast radius agora se estendeu para milhões de usuários finais que não fazem ideia do que "Workers KV" significa. Eles só sabem que seus apps favoritos não estão funcionando.

Essa progressão revela algo crucial sobre sistemas distribuídos modernos: nossas dependências têm dependências, e essas dependências têm dependências. Construímos uma teia intrincada onde um único fio pode derrubar seções inteiras.

Dependências Ocultas

Aqui está o que torna essa história particularmente atraente do ponto de vista de engenharia: a Cloudflare não é uma startup rodando sistemas com fita isolante e oração. Eles são uma das empresas de infraestrutura mais sofisticadas do mundo, com engenheiros brilhantes que entendem sistemas distribuídos melhor que a maioria.

Ainda assim, eles foram pegos nesta reação em cadeia.

Por quê? Por causa do que eu chamo de "problema das dependências invisíveis". Quando você está construindo em escala, você tende a pensar sobre suas dependências imediatas — os bancos de dados com os quais você conversa, as APIs que você chama, os serviços que você integra. Mas você raramente mapeia a árvore de dependências até três ou quatro níveis de profundidade.

Considere como a maioria das equipes de engenharia pensa sobre dependências:

Nosso App → Cloudflare Workers KV → ???

Como nós deveriamos estar pensando:

Nosso App → Cloudflare Workers KV → Armazenamento Terceirizado → Infraestrutura do Provedor → Seus Fornecedores → Suas Dependências...

Cada seta nessa cadeia representa um ponto potencial de falha. E aqui está o ponto crucial: quanto mais longe na cadeia a falha ocorre, mais difícil é prever, prevenir ou mesmo entender quando as coisas dão errado.

Sistemas Anti-Frágeis

Então, como construímos sistemas que não apenas sobrevivem a falhas como esta, mas na verdade ficam mais fortes com elas? A resposta está em abraçar o que Nassim Taleb chama de "anti-fragilidade" — sistemas que ganham com o caos em vez de apenas tolerá-lo.

Circuit Breaker (disjuntor)

Pense num disjuntor como o botão de parada de emergência de um trem. Quando as coisas começam a dar errado, ele previne que a situação se torne catastroficamente pior.

Aqui está um exemplo simplório de como você poderia implementar um:

enum class CircuitState { CLOSED, OPEN, HALF_OPEN }

class CircuitBreaker(
    private val threshold: Int = 5,
    private val timeoutMs: Long = 60_000
) {
    private var failureCount = 0
    private var lastFailure = 0L
    private var state = CircuitState.CLOSED
    
    suspend fun <T> call(operation: suspend () -> T): T {
        when (state) {
            CircuitState.OPEN -> {
                if (System.currentTimeMillis() - lastFailure > timeoutMs) {
                    state = CircuitState.HALF_OPEN
                } else throw Exception("Disjuntor está ABERTO")
            }
            else -> { /* prosseguir */ }
        }
        
        return try {
            operation().also { onSuccess() }
        } catch (e: Exception) {
            onFailure()
            throw e
        }
    }
    
    private fun onSuccess() {
        failureCount = 0
        state = CircuitState.CLOSED
    }
    
    private fun onFailure() {
        failureCount++
        lastFailure = System.currentTimeMillis()
        if (failureCount >= threshold) state = CircuitState.OPEN
    }
}

A beleza dos disjuntores: Eles falham rápido e falham com segurança. Em vez de deixar uma dependência problemática arrastar todo o seu sistema para baixo, você isola o problema e dá tempo para o componente falhando se recuperar.

Degradação Graciosa: A Arte de Cair Com Estilo

Já acabou, Jéssica?

Um dos aspectos mais elegantes de sistemas resilientes é sua capacidade de degradar graciosamente — continuar fornecendo valor mesmo quando partes do sistema estão falhando. Pense nisso como um carro que ainda pode te levar para casa mesmo quando o ar condicionado quebra.

Aqui está um exemplo:

data class UserProfile(
    val id: String,
    val name: String,
    val features: String,
    val message: String? = null
)

suspend fun getUserProfile(userId: String): UserProfile {
    return runCatching {
        // Primário: Workers KV rápido (50ms, recursos completos)
        workersKV.get(userId)
    }.recoverCatching {
        println("Workers KV indisponível, voltando para banco de dados")
        // Secundário: Banco + Redis (200ms, 90% dos recursos)
        database.getUser(userId)
    }.getOrElse {
        println("Banco indisponível, usando perfil estático")
        // Terciário: Padrões estáticos (5ms, 30% dos recursos)
        UserProfile(
            id = userId,
            name = "Usuário",
            features = "limitado",
            message = "Alguns recursos temporariamente indisponíveis"
        )
    }
}

Perceba o que está acontecendo aqui: cada fallback mantém a funcionalidade central enquanto reduz recursos. O usuário permanece logado e pode continuar usando o app, mesmo que perca alguma personalização. Isso é infinitamente melhor que uma página de erro em branco.

O Sistema de Triagem de Dependências

Nem todas as dependências são criadas iguais. O incidente da Cloudflare nos mostra a importância crítica de classificar nossas dependências pelo seu potencial de blast radius:

🔴 Dependências Críticas (Zona Vermelha) Essas são as que podem derrubar todo o seu sistema. No caso da Cloudflare, Workers KV caiu nessa categoria porque tantos outros serviços dependiam dele.

• Dependências críticas com potencial de reação em cadeia
• Nenhum fallback gracioso possível
• Requerem proteção imediata de disjuntor
• Deveriam ter múltiplos provedores redundantes

🟡 Dependências Importantes (Zona Amarela) Essas afetam funcionalidade mas não matam o sistema. Serviços de analytics frequentemente caem aqui.

• Dependências suaves que podem degradar graciosamente
• Perceptíveis quando falham, mas não catastróficas
• Bons candidatos para processamento assíncrono e lógica de retry

🟢 Dependências Opcionais (Zona Verde) Recursos nice-to-have que podem falhar sem ninguém perceber imediatamente.

• Caches de CDN edge, engines de recomendação, plataformas de teste A/B
• Podem dar timeout ou falhar silenciosamente
• Frequentemente seguras para desabilitar durante incidentes

O Elemento Humano

Aqui está algo que frequentemente é negligenciado em post-mortems técnicos: sistemas resilientes requerem equipes resilientes. O incidente da Cloudflare durou aproximadamente 2 horas e meia não apenas por causa de falhas técnicas, mas por causa de fatores humanos — tempo de detecção, procedimentos de escalação, tomada de decisão sob pressão.

A Psicologia da Resposta a Incidentes

Quando sistemas começam a falhar, engenheiros enfrentam o que psicólogos chamam de "sobrecarga de carga cognitiva". Você está simultaneamente tentando:

• Entender o que está acontecendo (diagnóstico)
• Prevenir que piore (contenção)
• Corrigir o problema imediato (mitigação)
• Comunicar com stakeholders (coordenação)
• Documentar tudo para depois (aprendizado)

Isso é muita coisa para fazer malabarismo quando seu telefone está vibrando com alertas e seu Slack está enchendo com mensagens "é só comigo ou..."

As organizações mais resilientes constroem sistemas que reduzem a carga cognitiva durante incidentes, não aumentam. Elas praticam regularmente, têm caminhos claros de escalação e, mais importante, abraçam a falha como uma oportunidade de aprendizado em vez de uma oportunidade de culpa.

Defesa em Profundidade

Pense em resiliência como o sistema de defesa de um castelo medieval. Você não depende apenas de uma parede forte — você tem fossos, múltiplas paredes, arqueiros e rotas de fuga. Sistemas modernos precisam da mesma abordagem em camadas:

• Camada de Aplicação: Circuit breakers, timeouts, degradação graciosa
• Camada de Serviço: Balanceamento de carga, health checks, auto-scaling
• Camada de Infraestrutura: Deploy multi-região, replicação, CDN
• Camada Organizacional: Treinamento de resposta a incidentes, post-mortems sem culpa, prática de engenharia de caos

O incidente da Cloudflare mostra o que acontece quando uma dessas camadas falha. As camadas técnicas (aplicação, serviço, infraestrutura) se mantiveram razoavelmente bem, mas a camada de gerenciamento de dependência tinha um ponto cego.

Monitoramento Que Realmente Importa

A maioria dos sistemas de monitoramento é ótima em te dizer que algo está quebrado. No que eles são terríveis é em te dizer quão quebradas as coisas estão e quão longe o dano está se espalhando.

Após incidentes como o da Cloudflare, equipes inteligentes adicionam "indicadores de blast radius" aos seus dashboards:

• Profundidade da cadeia de erros: Quantas camadas de serviço estão afetadas
• Porcentagem de impacto no cliente: Fração de usuários experimentando problemas
• Fan-out de dependência de serviço: Número de serviços que poderiam ser afetados
• Nível de confiança na recuperação: Quão certos estamos de que nossa correção vai funcionar

Essas métricas ajudam a responder a pergunta crítica durante um incidente: "Isso está melhorando ou piorando?"

Mudança de Mentalidade

Aqui está um insight contraintuitivo do incidente da Cloudflare: focar no Tempo Médio para Recuperação (MTTR) é mais valioso que obsessivamente se concentrar no Tempo Médio Entre Falhas (MTBF).

Por quê? Porque você não pode controlar quando dependências terceirizadas falham, mas você definitivamente pode controlar quão rápido você detecta, responde e se recupera dessas falhas.

Equipes de pit stop da Fórmula 1 otimizam sua resposta a incidentes:

• Detecção: Alertas automatizados que acordam pessoas (< 2 minutos)
• Resposta: Runbooks claros que qualquer um pode seguir (< 5 minutos)
• Mitigação: Procedimentos praticados que funcionam sob pressão (< 30 minutos)
• Recuperação: Restauração gradual com capacidade de rollback (< 60 minutos)

A Cloudflare levou aproximadamente 2 horas e meia para recuperação completa, mas começou a ver sinais de recuperação cerca de 2 horas após o início do incidente.

Lições Aprendidas

1. Identificar os Pontos Cegos

2. Implementar "Degradação Graciosa" Logo de Cara

Em vez de tratar fallbacks como coisas pra tratar no futuro, priorize isso na sua arquitetura. Todo fluxo crítico de usuário deveria ter pelo menos um modo de fallback (e, dependendo da cricitidade, eu recomendo até mesmo dois modos de fallback).

3. Testar Falhas em Ambiente Controlado

Comece pequeno: Desabilite um serviço não crítico por 10 minutos durante horários de baixo tráfego. Observe o que quebra. Conserte essas coisas. Gradualmente trabalhe até componentes mais críticos.

O objetivo não é quebrar coisas por diversão — é descobrir como seu sistema se comporta sob estresse antes que seus usuários o façam.

4. Construir Memória Muscular de Resposta a Incidentes

A hora de descobrir seu processo de resposta a incidentes não é durante um incidente real. Execute "game days" mensais onde você simula falhas e pratica sua resposta.

5. Abraçar a Prática de Escrever Post-Mortem

Quando as coisas dão errado, resista ao impulso de encontrar a "pessoa responsável". Em vez disso, pergunte: "Que condições do sistema tornaram essa falha possível?" e "Como podemos tornar impossível repetir o mesmo erro?"

Complexidade Requer Pensamento Sistêmico

O incidente da Cloudflare não é realmente sobre a Cloudflare. É sobre o desafio fundamental de construir sistemas confiáveis num mundo interconectado onde a confiabilidade do seu sistema é apenas tão forte quanto sua dependência transitiva mais fraca.

Essa realidade requer uma mudança em como pensamos sobre design de sistema:

• De prevenir falhas para conter o raio de impacto (blast radius)
• De uptime perfeito para degradação graciosa
• De cultura de culpa para cultura de aprendizado
• De monitoramento reativo para observabilidade preditiva

Conclusão

A história da queda da Cloudflare é uma oportunidade de aprendizado. Ela nos mostra que mesmo as empresas de infraestrutura mais sofisticadas do mundo podem ser derrubadas por falhas que não anteciparam em dependências que mal sabiam que existiam (ou mesmo que confiaram plenamente que ficaria de pé).

Mas aqui está o ponto central: O objetivo não é prevenir todas as falhas possíveis, o que é impossível, mas construir sistemas e equipes que tenham jogo de cintura. Incerteza e situações inesperadas são a única certeza que temos no meio do caos.

Na próxima vez que você estiver projetando um sistema, não pergunte apenas "Como prevenir que isso falhe?" Pergunte em vez disso:

• "Quando isso falhar (não se), quão longe o dano se espalhará?"
• "Quão rapidamente saberemos que algo está errado?"
• "Qual é a funcionalidade viável mínima que precisamos manter?"
• "Como podemos praticar a recuperação dessa falha?"

A internet é um sistema complexo e interconectado construído sobre confiança, redundância e a suposição de que a maioria das coisas funciona na maioria das vezes. O incidente da Cloudflare nos lembra que essa suposição, embora geralmente verdadeira, também é ocasionalmente catastroficamente falsa.

Os sistemas mais resilientes não são aqueles que nunca falham — são aqueles que falham de maneiras previsíveis e de modo que o dano possa ser contido e que se recuperam rapidamente. Construa para a falha que você pode imaginar, e estará melhor preparado para aquelas que não pode.