Cloudflare reduz pela metade o atraso nos builds de DNS e corta uso de memória em 85%

O ponto central é o que o Zone Builder da Cloudflare deixou de fazer. Antes, qualquer mudança de configuração de zona disparava uma reconstrução completa: ler todos os registros, converter para chaves do Quicksilver, comparar e gravar só o que mudou. A escrita final já era enxuta, mas a leitura, a codificação e a comparação cobriam a zona inteira, que precisava caber na memória. Hoje há zonas com mais de 20 milhões de registros, e a empresa espera chegar a centenas de milhões.

A solução tem duas peças. Um planner escolhe entre cinco tipos de build (só recursos, recursos e metadados, apex e metadados, purge e zona completa) e só aceita o menor que consiga provar seguro. A regra é que cada chave escrita seja idêntica, byte a byte, ao que um build completo escreveria. Na dúvida, vai de zona completa. Um scheduler unificado junta o trabalho pendente da mesma zona, soma nomes e metadados, e trata purge como prioridade. O commit de offsets no Kafka é do tipo soft: o offset só avança quando todas as mensagens anteriores terminam. Se o serviço reinicia, ele reprocessa em vez de perder uma mudança. Antes de executar, o builder lê um snapshot novo em réplicas, porque o banco pode ter mudado desde o evento.

Em 2022, segundo o próprio texto da Cloudflare, o Zone Builder recebia cerca de 250 mudanças de registro por segundo, e os builds por registro já eram em média 150 vezes mais rápidos que os completos. O passo seguinte, anunciado na época, era fazer o mesmo para configurações de zona. Agora o volume é de cerca de 700 eventos de registro por segundo, mais cerca de 100 outros eventos. Em 2 de novembro de 2026, o CEVIU noticiou "Cloudflare reduz à metade o atraso de build de DNS e corta em 85% o uso de memória", e em 3 de novembro de 2026 voltou ao tema com "Cloudflare reduz pela metade o atraso nos builds de DNS e corta o uso de memória em 85%". Esta matéria detalha o mesmo anúncio com os números de pico (79 GiB para 12 GiB) e a mediana (7,7 para 3,3 segundos).

Para quem opera pipelines de propagação ou sistemas orientados a eventos, o caso mostra um padrão útil: reconstruir tudo é simples e seguro, mas deixa de escalar quando o dado cresce. A saída não foi relaxar a correção. Foi investir em provar equivalência, com testes que comparam build completo e direcionado, e em ter fallback conservador. Também vale notar que a folga de memória permitiu encurtar esperas de resiliência, o que é uma forma indireta de ganhar latência.