When a Cloudflare customer updates a single DNS record, that change used to trigger a complete rebuild of the entire zone, touching every record in it even if 99% of them hadn’t changed.
The fix wasn’t to throw more hardware at the problem, nor was it to redesign the architecture from the ground up. It was to do less work.
Cloudflare’s engineering team built what they call a “targeted build planner,” a system that determines exactly which parts of a DNS zone need to be rebuilt when something changes and rebuilds only those. A DNS zone is the complete collection of records and settings for a domain. If a customer changes one address record, there’s no reason to process the other ten million records in that zone. The new planner understands this. It skips the unnecessary work.
The numbers speak clearly. Peak memory usage dropped from 79 gigabytes to 12 gigabytes, a reduction of 85%, and median build time fell from 7.7 seconds to 3.3 seconds, cutting propagation delay roughly in half. Full zone rebuilds fell by 40%.
This matters beyond Cloudflare’s internal metrics. Faster propagation means that DNS changes (the updates that tell the internet where to find your website) reach users more quickly across the globe. A smaller memory footprint means Cloudflare can handle more customers’ zones with the same infrastructure. At Cloudflare’s scale, with millions of customers, that efficiency compounds enormously.
This kind of engineering is easy to underestimate. The obvious approach is to rebuild everything every time, which is safe by default. The disciplined approach is to prove rigorously exactly what needs to change and then limit the work to that specific set, nothing more. Building something that correctly does less is significantly harder than building something that blindly does everything.
The harder part of this project was proving the shortcuts were safe. Any path that produced inconsistent DNS data would have been worse than the original inefficiency. The Cloudflare team spent much of the development period building a formal classification of which settings affect which records, running targeted builds in parallel against production traffic, and writing equivalence tests that compared every output byte-for-byte against full builds. They shipped nothing without systematic proof.
There’s a lesson here that extends beyond DNS infrastructure. Performance improvements in complex systems rarely come from buying bigger machines. They come from rethinking what work actually needs to happen, cutting what doesn’t need to, and then proving rigorously that the resulting shortcut holds in production. That takes more upfront thinking than the brute-force approach. It scales, though. The brute-force approach hits a wall.
If your systems are slowing down as they grow, adding capacity is often just an expensive way to delay the reckoning. The better question is what work you’re doing that doesn’t actually need to happen. Ask it now.
Want to explore how smart engineering could improve your systems? Let’s talk.