随着 DNS 区域复杂性的增加，处理海量域名的更新带来了巨大的工程挑战。Cloudflare 报告称，其中一些区域现在包含超过 2000 万条记录，预计这些数字将达到数亿。此前，系统依赖“全量构建”来传播更改。全量构建会读取一个区域当前的整个数据库状态，将每条记录转换为权威服务器使用的格式，并将其与 Cloudflare 分布式键值存储 Quicksilver 中的现有数据进行比较。对于海量区域，这一过程效率低下，因为整个区域必须保存在内存中，这往往会超出可用容量，并在传播流水线中造成瓶颈。
为了解决这个问题，Cloudflare 实施了一个定向构建规划器，用于识别为维持正确状态所需的最小更改集。该系统现在将更新分为五种特定的构建类型：“仅资源”（标准的 A、AAAA、TXT 和 CNAME 更改）、“资源和元数据”（名称服务器和通配符更改）、“Apex 和元数据”（如 Universal SSL 等设置）、“清除”（删除区域）以及“全量区域”（仅在无法证明更改安全到特定目标时使用）。规划器通过在代码中追踪每个设置来确定其影响，从而确保安全性。如果更改具有歧义——例如仅包含时间戳且未指明更改内容的更新——系统将默认执行全量构建，以避免提供过时或错误的数据。
通过统一调度器进一步提高了效率，该调度器将同一区域的多个待处理更改合并到单个构建操作中。这防止了系统在多个更新连续到达时执行冗余工作。为了保持可靠性，系统使用 Kafka 的“软提交”机制；虽然构建可能会乱序完成，但只有在所有前置消息完成后，Kafka 偏移量才会推进。这确保了如果工作节点重启，不会丢失任何客户更改。然而，对于最大的区域存在特定的权衡：如果区域超过固定的记录数量阈值，系统将拒绝执行全量构建。这防止了单个海量区域阻塞整个 Kafka 分区，即使这意味着在极少数情况下，当全量构建被要求但技术上无法在内存限制内完成时，系统必须手动重建单个名称。