A medida que las zonas de DNS crecen en complejidad, procesar actualizaciones para dominios masivos presenta un desafío de ingeniería significativo. Cloudflare informó que algunas de sus zonas contienen ahora más de 20 millones de registros, con expectativas de que estas cifras alcancen cientos de millones. Anteriormente, el sistema dependía de 'construcciones completas' para propagar los cambios. Una construcción completa lee el estado actual de la base de datos de una zona, convierte cada registro a un formato utilizado por los servidores autoritativos y los compara con los datos existentes en Quicksilver, el almacén de clave-valor distribuido de Cloudflare. Para zonas masivas, este proceso es ineficiente porque la zona completa debe mantenerse en memoria, superando a menudo la capacidad disponible y creando cuellos de botella en el flujo de propagación.
Para resolver esto, Cloudflare implementó un planificador de construcción dirigida que identifica el conjunto más pequeño de cambios necesarios para mantener un estado correcto. El sistema ahora clasifica las actualizaciones en cinco tipos de construcción específicos: 'Solo recursos' (cambios estándar A, AAAA, TXT y CNAME), 'Recursos y metadatos' (cambios de nameserver y comodín), 'Apex y metadatos' (ajustes como Universal SSL), 'Purge' (eliminación de una zona) y 'Zona completa' (utilizada solo cuando no se puede demostrar que un cambio es seguro para un objetivo específico). El planificador garantiza la seguridad rastreando cada ajuste a través del código para determinar su impacto. Si un cambio es ambiguo —como una actualización de solo marca de tiempo que no especifica qué cambió— el sistema recurre por defecto a una construcción completa para evitar servir datos obsoletos o incorrectos.
La eficiencia se mejora aún más mediante un planificador unificado que combina múltiples cambios pendientes para la misma zona en una sola operación de construcción. Esto evita que el sistema realice trabajos redundantes cuando llegan varias actualizaciones en rápida sucesión. Para mantener la fiabilidad, el sistema utiliza 'soft committing' con Kafka; aunque una construcción pueda terminar fuera de orden, el desplazamiento de Kafka solo avanza una vez que todos los mensajes precedentes se completan. Esto garantiza que, si un trabajador se reinicia, no se pierdan los cambios de los clientes. Sin embargo, existe una compensación específica para las zonas más grandes: si una zona supera un umbral fijo de recuento de registros, el sistema se niega a realizar una construcción completa. Esto evita que una sola zona masiva bloquee una partición completa de Kafka, incluso si esto significa que el sistema debe reconstruir manualmente nombres individuales en casos raros donde una construcción completa sería necesaria pero técnicamente imposible de completar dentro de los límites de memoria.