The reading room · Digna Legi
How we halved DNS build delay and cut memory use by 85%
/100
80–100: high value. 70–79: worth the time. Below 70: below the usual publication threshold.
Evidence-reviewed score based on available publisher text. The supplied text contains sampling gaps; omitted sections and visuals were not assessed. Results rely on internal measurements: the 24-hour scheduler comparison and subsequent delay reductions from changed safeguards have different evidential scopes.
Scores reflect one reader’s profile, not an objective quality rating. Best is a separate personal selection.
How scoring works →This brief · about 3 min with detail
Why read this
Smaller DNS rebuilds require explicit knowledge of dependencies and old state; their memory savings can also make protective waiting periods safely shorter.
AI brief · Checked against source text
The main idea
Cloudflare reduced DNS update work by replacing many complete-zone rebuilds with plans that rebuild only affected names and shared metadata, then combining queued changes for each zone. Each targeted plan must produce the same relevant output as a full rebuild in Quicksilver, Cloudflare’s distributed key-value store. Lower memory use and safeguards against stale database reads then allowed shorter waits, roughly halving median completion delay.
Some background helpful. Basic familiarity with DNS records, databases, and message queues.
Go a little deeper
Treat events as evidence, not current truth
A change notification describes the past; the database may change again before execution. Cloudflare therefore plans conservatively from the event, then rereads publication settings and domain membership before writing. This can expand a rebuild, cancel it, or turn it into deletion. Database replicas also reject reads when they lag behind the event, making a shorter waiting buffer safe.
Combine work without discarding obligations
The scheduler merges queued names and metadata updates, but tracks message acknowledgments separately. A full rebuild may make individual names unnecessary without making their messages disposable. Because the queue’s committed position can advance only past completed earlier messages, one slow build can obstruct unrelated changes. After a restart, Cloudflare accepts repeated work rather than risk losing an update.
Separate cheaper work from shorter waits
The initial change mainly improved extreme delays and memory: peak working memory fell from 79 to 12 GiB, while typical delays barely changed. Shortening rebuild intervals and the database-lag buffer subsequently reduced median completion delay from about 7.7 to 3.3 seconds. These measurements end when Quicksilver is written; they exclude distribution across Cloudflare’s network and are not individual-zone guarantees.
A case from the article
A certificate setting reaches DNS records
Enabling or disabling Universal SSL can change certificate-issuance permission records at the apex—the bare domain, such as example.com—as well as metadata. A seemingly unrelated product setting therefore needs more than a settings update, but less than rebuilding every DNS record. Tracing that dependency lets Cloudflare choose an apex-and-metadata build while preserving the output of a full rebuild.
How the case is made
Cloudflare supports its account with equivalence tests, production-stream mirror comparisons, and a 24-hour comparison of old and new schedulers.
Where the idea has limits
Above a record-count threshold, full builds cannot finish. Cloudflare instead rebuilds the apex, metadata and every name identified by queued events; it can manually rebuild individual names in rare remaining cases.
A question to take away · from Digna Legi
Where does your system repeat expensive work because a change notification fails to identify what changed?
What the original adds
The source also details five build types, removal of obsolete stored keys, and rollout by domain-name hash to keep shared metadata under one scheduler.
About this brief
AI-written, then separately checked for source support, useful detail and clarity. The author’s claims and our editorial question are kept separate. The original remains the author’s work. How we select and summarise →
How was this brief?
Rate this summary, separately from the author’s article.
Optional. Saved in this browser; shared only if you allow analytics.
How was the original article?
Rate the author’s original after reading it.
Optional. Saved in this browser; shared only if you allow analytics.
Digna legi. Worth reading.