How we halved DNS build delay and cut memory use by 85%
Comments on “How we halved DNS build delay and cut memory use by 85%”
Claim-checked. Scored by all three judges, and its checkable claims were compared with the sources it cites. How far stories are checked
Cloudflare describes how its DNS Zone Builder now plans the smallest build it can prove safe, rather than rebuilding whole zones when a setting changes, and merges queued work per zone in one scheduler. Peak memory fell 85% (79 to 12 GiB), and median delay from change to Quicksilver write halved, from about 7.7 to 3.3 seconds. About 93% of builds no longer rebuild the full zone. The figures are Cloudflare's own and not independently verified. The mirror comparison of delay covered one 24-hour period.
Why it ranked
No. 10 of 107 with a score of 0.65. The panel rated it highest on substantiated (0.93) and technical depth (0.92), lowest on audience breadth (0.43). Placed No. 10, No. 19 by score alone: the placement terms moved other stories past it.
- AI judgeJudge 2claude-haiku-5-5
- Detailed engineering write-up of a large DNS propagation pipeline redesign with concrete benchmarks, mirror validation and latency/memory figures. Strong substantiation and technical depth; audience is narrower than general tech, and it is an original vendor case study rather than broad news.
- AI judgeJudge 3gpt-5.6-luna
- Detailed engineering account of targeted DNS builds, scheduling, Kafka correctness, testing, rollout, and measured latency/memory gains. It is highly reproducible and practically useful, though focused on one large provider’s infrastructure.
Each judge wrote its line after answering the rubric, with the site and the author still hidden. Every answer behind this is in the table under Score.
Score
0.65total under rubric v2.3
- Significance0.60
- Reader interest0.78
- Audience breadth0.43
- Practical relevance0.68
- Substantiated0.93
- Technical depth0.92
- New information0.92
- Counts against: Promotional0.11
- Counts against: Overclaim0.19
Each judge’s answer per question (0–1), their mean and spread, and what the question adds to the score (weight × mean).
| Question | Judge 1 | Judge 2 | Judge 3 | Mean | Spread | Weight | Contribution (weight times mean) |
|---|---|---|---|---|---|---|---|
| SignificanceHow much does this change what people in tech know or can do? | 0.57 | 0.50 | 0.72 | 0.60 | 0.22 | +0.24 | +0.143 |
| Reader interestWould a well-informed senior engineer or tech founder want to read this today, and likely pass it on? | 0.75 | 0.70 | 0.90 | 0.78 | 0.20 | +0.26 | +0.204 |
| Audience breadthHow many people who build technology does it concern? | 0.33 | 0.40 | 0.55 | 0.43 | 0.22 | +0.13 | +0.055 |
| Practical relevanceHow useful is it to someone who builds software or tech products? | 0.72 | 0.55 | 0.78 | 0.68 | 0.23 | +0.22 | +0.151 |
| SubstantiatedHow well is it backed? Consider whether it is the primary source, and whether its main claims come with data, code, a demo, a reproducible method or citations. | 0.97 | 0.85 | 0.96 | 0.93 | 0.12 | +0.05 | +0.046 |
| Technical depthHow technically substantive is it? | 0.97 | 0.85 | 0.93 | 0.92 | 0.12 | +0.05 | +0.046 |
| New informationDoes it contain information absent from the stories covered in the last 7 days (list provided)? | 0.89 | 0.90 | 0.96 | 0.92 | 0.07 | +0.05 | +0.046 |
| PromotionalIs it mainly marketing with little substance (a press release, ad or sponsored post with no real information)? A launch post that carries real news is not promotional. | 0.05 | 0.20 | 0.08 | 0.11 | 0.15 | −0.19 | −0.021 |
| OverclaimDo the headline or conclusions claim more than the body supports? | 0.30 | 0.20 | 0.08 | 0.19 | 0.22 | −0.11 | −0.021 |
| Sum of contributions | +0.649 | ||||||
| Claim-check penalty | 0.000 | ||||||
| Total, as published | 0.649 | ||||||
Spread is the highest minus the lowest judge answer. marks a spread above 0.40: the judges disagree, and the story is marked contested.
The badge for this ranking, for the author's page or anyone's: one line of HTML, and it links back here.
<a href="https://rubric.hrih.si/editions/2026-11-03/10/"><img src="https://rubric.hrih.si/badge/2026-11-03/10.svg" alt="Ranked #10 on Rubric, 3 Nov 2026" width="238" height="28"></a>Claim check
Claim check: 1 matches source · 6 no source given · 1 couldn’t check. Each claim is compared with the source the article itself cites; a flag is published only when both checkers agree.
No source givenNumber
Cloudflare's targeted build planner and unified scheduler together cut Zone Builder peak memory by 85%.
The article gives no link or citation for it.
The article says “Peaks fell from 79 GiB to 12 GiB, an 85% reduction”
The source says No source to compare with.
No source givenNumber
Median build completion delay fell from about 7.7 seconds to about 3.3 seconds, a halving.
The article gives no link or citation for it.
The article says “Together, these halved the median build completion delay, from about 7.7 seconds to about 3.3 seconds”
The source says No source to compare with.
Couldn’t checkNumber
The Zone Builder now receives about 700 DNS record changes per second, up from about 250 in 2022.
The source was unreachable, paywalled or too long, or the two checkers disagreed.
The article says “the Zone Builder received about 250 DNS record changes per second. Today it receives about 700, nearly three times as many”
The source says No passage could be compared.
Source cited by the article: blog.cloudflare.com/dns-build-improvement
Matches sourceNumber
In 2022, per-record builds were 150 times faster than full builds on average, and 4,250 times faster on a one-million-record test zone.
The cited source says the same thing.
The article says “In 2022, per-record builds were 150 times faster than full builds on average. On a test zone with one million records, per-record builds were 4,250 times faster”
The source says “per-record builds are on average 150x faster than full builds”
Source cited by the article: blog.cloudflare.com/dns-build-improvement
No source givenNumber
The largest p99 build completion delay spike fell from 14.6 minutes to 1.21 minutes, a 12-fold reduction.
The article gives no link or citation for it.
The article says “the largest p99 spike fell from 14.6 minutes to 1.21 minutes, a 12-fold reduction”
The source says No source to compare with.
No source givenNumber
Over 24 hours, 92.95% of builds avoided rebuilding the complete zone and full builds were 7.04%.
The article gives no link or citation for it.
The article says “Together, 92.95% of builds avoided rebuilding the complete zone. Full builds were the remaining 7.04%”
The source says No source to compare with.
No source givenNumber
Average working-set memory fell from 49 GiB to 7 GiB, an 86% reduction.
The article gives no link or citation for it.
The article says “fell from an average of 49 GiB to 7 GiB, an 86% reduction”
The source says No source to compare with.
No source givenCausal conclusion
Because fewer full builds hold back Kafka offsets, consumption now tracks the rate at which events arrive instead of bursting up to 1,550 messages per second.
The article gives no link or citation for it.
The article says “With fewer of them, we now consume Kafka at the rate events arrive, instead of falling behind and catching up in bursts of up to 1,550 messages per second”
The source says No source to compare with.
Also covered by
No other coverage was clustered with this story.
Elsewhere
Elsewhere: HN 170 pts, front page
Recorded for context only, checked 3 Nov 2026, 05:47 UTC. It played no part in the ranking.