A interrupção do serviço Cloudflare na noite passada foi causada pela seguinte instrução SQL. Anteriormente, essa consulta SQL funcionava perfeitamente, consultando apenas informações de colunas no banco de dados padrão. No entanto, ontem eles atualizaram as permissões de alguns usuários, o que fez com que este SQL retornasse informações da solução tanto do banco de dados padrão quanto do banco de dados r0 subjacente. Quando ajustaram as permissões, ninguém pensou em modificar este SQL de acordo. Como resultado, o número de resultados da consulta dobrou, fazendo com que o tamanho do arquivo de resultados também dobrasse. O arquivo que originalmente continha cerca de 60 características passou a conter cerca de 120 características. Isso nos leva a uma característica fundamental do design. Para otimizar o desempenho, o módulo anti-crawler da Cloudflare pré-aloca uma quantidade fixa de memória e define um limite máximo: ele suporta no máximo 200 recursos. O limite foi inicialmente definido de forma bastante permissiva, já que apenas 60 foram efetivamente utilizados, deixando uma margem de segurança de mais de três vezes. No entanto, surgem problemas quando o arquivo de funcionalidades excede o limite de 200 funcionalidades devido a dados duplicados. O código Rust possui uma verificação que gera um erro 500 caso a contagem de funcionalidades exceda o limite. Pior ainda, esse arquivo de recursos é gerado automaticamente a cada 5 minutos e enviado rapidamente para todos os servidores do mundo. Como os ajustes de permissão são enviados para cada nó do banco de dados incrementalmente, a cada 5 minutos, dependendo do nó em que a consulta for executada, um arquivo correto ou incorreto poderá ser gerado. Isso levou a um fenômeno muito estranho: o sistema funcionava e depois apresentava falhas intermitentes, às vezes voltando ao normal e outras vezes travando completamente. Esse sintoma levou os engenheiros a suspeitarem de um possível ataque DDoS. Por coincidência, a página de status da Cloudflare (hospedada por terceiros e completamente independente da infraestrutura da Cloudflare) também ficou fora do ar nesse momento, aumentando ainda mais as suspeitas de um "ataque". Isso os levou a pensar na direção errada ao identificar o problema, desperdiçando algum tempo. Só depois que os ajustes de permissão foram gradualmente implementados em todos os nós, e cada nó começou a gerar arquivos corrompidos, o sistema entrou em um estado de falha estável. Somente então os engenheiros conseguiram finalmente identificar o problema real e corrigi-lo. A interrupção começou por volta das 19h28 do dia 18 de novembro em Pequim, foi inicialmente restabelecida às 22h30 e totalmente restaurada à 01h06 do mesmo dia, durando um total de cerca de 5 horas e meia. Foi a maior interrupção da Cloudflare desde 2019.
