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

O ponto de partida é o Zone Builder, que converte o estado do banco em chaves que os servidores DNS autoritativos da Cloudflare entendem e grava só o que mudou no Quicksilver, o key-value store distribuído da empresa. Em 2022, ele recebia cerca de 250 alterações de registro por segundo. Hoje recebe cerca de 700, mais uns 100 eventos de outro tipo, como mudanças de configuração de zona. Algumas zonas já passam de 20 milhões de registros, e a expectativa é chegar a centenas de milhões.

O problema era o tipo de trabalho. Um build completo lê, codifica e compara todos os registros, e mantém a zona inteira em memória. O planner agora escolhe entre cinco tipos de build: só recursos (nomes específicos), recursos e metadados, apex e metadados, purge e zona completa. A regra é que toda chave escrita por um build direcionado seja idêntica, byte a byte, à de um build completo. Sem prova disso, vai de zona completa. Acima de um limite fixo de registros, porém, o Zone Builder nunca escala para build completo, porque ele não terminaria e travaria a partição Kafka. O scheduler unificado funde eventos da mesma zona, preserva as mensagens Kafka pendentes e usa soft commit, então prefere repetir trabalho a perder uma alteração. Testes de equivalência comparam builds completos e direcionados para nameserver, wildcard e apex.

Em 2022, segundo o próprio texto, os builds por registro já eram em média 150 vezes mais rápidos que os completos, e o passo seguinte óbvio era fazer o mesmo para configurações de zona. É isso que chegou agora. 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", sobre o mesmo anúncio, com os mesmos números de eventos por segundo.

Para quem opera sistemas com grande volume de dados derivados, a lição é de design: reconstruir tudo é simples e seguro, mas deixa de escalar. Segundo o texto, a troca só foi viável porque a Cloudflare investiu em provar equivalência e manteve o build completo como fallback. Quem pensa em atualizações incrementais deve ler isso como um aviso de que a maior parte do esforço está na verificação, não na otimização.