Cloudflare reduz à metade o atraso de build de DNS e corta em 85% o uso de memória

A Cloudflare descreve como o Zone Builder, etapa que converte alterações de DNS em dados usados pelos servidores autoritativos, passou a lidar com cerca de 700 mudanças de registros por segundo, contra cerca de 250 em 2022, mais cerca de 100 outros eventos, como mudanças de configuração de zona. Algumas zonas já passam de 20 milhões de registros. O gargalo era o tipo de trabalho: um build completo lê todos os registros, codifica, compara e mantém a zona inteira na memória. Nas maiores zonas, isso nem cabe.

O targeted build planner escolhe entre cinco tipos de build: só recursos, recursos e metadados, apex e metadados, purge e zona completa. A regra é que toda chave gravada num build direcionado seja idêntica, byte a byte, à de um build completo. Sem prova disso, a empresa faz o build completo. Acima de um limite fixo de registros, o sistema nunca escala para build completo e reconstrói apex, metadados e os nomes dos eventos na fila. O novo scheduler unifica o trabalho de registros e de zona, agrupa eventos da mesma zona e só avança o offset do Kafka quando todas as mensagens anteriores terminaram (soft commit). Em caso de reinício, prefere repetir trabalho a perder uma mudança. O resultado informado: pico de memória 85% menor e tempo entre a mudança de DNS e a gravação no Quicksilver reduzido pela metade.

Sobre este pipeline de DNS, a cobertura anterior do CEVIU não traz um marco direto. O texto da Cloudflare compara com o próprio post de 2022, que já tinha builds por registro cerca de 150 vezes mais rápidos que os completos. O passo seguinte, aplicar a mesma lógica às configurações de zona, é o que foi entregue agora.

Para quem opera infraestrutura de DNS ou depende de provedores que a operam, o caso mostra um padrão: escalar não é só aguentar mais eventos, é evitar trabalho proporcional ao tamanho do cliente. Para gestores de TI, a leitura é que propagação mais rápida de mudanças reduz a janela de dados desatualizados na borda. A abordagem de cair para o build completo quando há incerteza também é um bom critério de segurança para qualquer otimização em sistemas críticos.