Cloudflare reported on November 2, 2026 that changes to its DNS update pipeline cut peak working-set memory by 85%, freeing capacity to shorten the waits before changes reach its distribution system. Its engineering account describes replacing unnecessary full-zone rebuilds with smaller jobs. The results are Cloudflare's own measurements, and the reported delay excludes distribution across its network.
For developers running event-driven systems, the useful detail is how Cloudflare decided which work it could safely skip. Some DNS zones now contain more than 20 million records. A setting change could force the system to read and process an entire zone, even when only a small part of its output needed updating, according to the post.
Smaller builds need better events
The Zone Builder converts database state into keys used by Cloudflare's authoritative DNS servers, then writes changes to Quicksilver, its distributed key-value store. Previously, a full build could discover what needed changing by reading everything. Cloudflare's targeted planner instead uses event details to choose the affected DNS names and metadata. Changing Universal SSL, for example, can require rebuilding the bare domain's certificate-authority authorization records and metadata without touching every record.
That demands more information from event producers. Cloudflare added changed fields and settings, including old and new values when available. Timestamp-only events can still mean either bookkeeping or a change elsewhere that needs rereading. The planner normally retains a full build when it cannot establish a smaller safe scope. It also rereads current publication state before execution because the database may have changed while the event waited.
One exception deserves attention: above a fixed record-count threshold, the builder never escalates to a full-zone build. Those zones cannot fit in memory. It rebuilds the apex, metadata and names identified by queued events instead. Cloudflare acknowledges the tradeoff and says rare remaining cases can require manually rebuilding individual names. The optimization has an operational escape route, with limits that matter when interpreting its correctness claims.
A slow build can delay unrelated changes
Cloudflare also combined separate record and full-zone schedulers. Pending events for the same zone can now merge into one job. The scheduler keeps the required DNS work and Kafka acknowledgements separate, preserving both through retries. A slow earlier message prevents the partition's committed position from advancing past it, even when later jobs finish. Reducing oversized jobs therefore helps unrelated work avoid replay after a restart.
Cloudflare reports that peak working-set memory fell from 79 GiB to 12 GiB. In its 24-hour comparison, old and new schedulers consumed the same events and read the same database, while writing to separate Quicksilver environments. The largest p99 build-delay spike fell from 14.6 minutes to 1.21 minutes. That describes the worst spike in the comparison, rather than a typical event's speedup.
The later reduction in everyday delay also involved changing deliberate waits. With cheaper builds and checks that reject reads from lagging database replicas, Cloudflare shortened rebuild intervals on most plans and the event buffer. It reports median build completion delay falling from about 7.7 seconds to about 3.3 seconds. The measurement stops at the write to Quicksilver. It excludes subsequent network distribution and provides no latency guarantee for an individual zone.
The remaining full builds have a purpose
To check the smaller jobs, Cloudflare describes byte-for-byte equivalence tests and a mirror builder that reads production events but serves no customer traffic. A comparer checks a 20% sample of zones for differing output. These are Cloudflare's reported checks, not tests performed by MrKeyoor.
Cloudflare says it will move more events to targeted builds as it learns exactly what they change. First publication still needs every record written, and some changes still require every record checked. Its stated plan makes the next useful question specific: which remaining events can carry enough information to reduce work without leaving stale DNS data behind?