The reading room · Digna Legi
How we saved 100 terabytes of memory by optimizing 1.1.1.1’s DNS cache
/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. Full evidence is available, but the subject is systems-heavy and may be less useful if the reader wants product or leadership material that day.
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
Original article ↗ · about 12 min (publisher estimate)
Why read this
Cloudflare saved cache memory by changing representation: removing duplicated, oversized, and scattered storage without changing DNS behavior.
AI brief · Checked against source text
The main idea
Cloudflare’s central claim is that large cache savings came from changing representation, not from changing DNS behavior. The useful pattern is to remove storage that no longer earns its keep after insertion: spare vector capacity, duplicated section pointers, repeated owner names, oversized enum variants, and scattered heap allocations. Because the cache contains over 250 billion entries, byte-level reductions became roughly 100 terabytes of freed working-set memory while also improving locality and allocation behavior.
Technical reading. Comfort with caches, heap allocation, Rust structs/enums, and basic DNS records.
Go a little deeper
Immutability changes the right container
Once a DNS response is stored, Big Pineapple does not mutate it. That makes growable containers wasteful: a vector carries pointer, length, and capacity, while a boxed slice can keep only the fixed data. The same logic applies to strings. The broader mechanism is not “use smaller types” but “switch from construction-time structures to storage-time structures after the object’s lifecycle changes.”
Layout beats field counting
The article repeatedly shows that memory savings are not just the visible size of deleted fields. Rust alignment and padding mean removing or packing small fields can shrink the surrounding structure by more than the field’s own nominal size. This matters at scale because developers who optimize by adding up fields manually may miss the real object-size boundary the allocator and CPU actually see.
Common cases deserve inline treatment
The enum problem is a frequency problem as much as a type-size problem. A and AAAA records dominate the measured traffic mix, but the enum had to reserve space for the largest variant, NAPTR. Boxing the rare large variants lets common small records stop paying for uncommon shapes, though the article also tracks the new allocator and locality costs created by boxing.
Packed bytes can preserve structure where it matters
The final representation avoids both extremes: it does not cache full DNS wire messages, but it also stops storing every record as a parsed enum. Record data becomes a single contiguous byte buffer, while the rest of the cache entry remains structured. That preserves useful metadata and response logic while enabling direct copies for many record types and better CPU cache locality.
A case from the article
Owner names removed when the key already has them
A query for a domain often returns records owned by that same domain, so storing the owner name inside every cached record duplicates information already present in the cache key. Cloudflare changed the record owner to an optional field: absent means reconstruct it from the query at read time; present means store the full name for cases like CNAME chains where the owner differs.
How the case is made
The case is made through Rust data-structure analysis, synthetic cache benchmarks, and production resident-memory measurements during rollout.
Where the idea has limits
The benchmark intentionally approximated production traffic rather than reproducing it exactly, and production memory includes process data outside the cache, so per-entry savings do not translate one-for-one into resident-memory reductions.
A question to take away · from Digna Legi
Where does your system still store future flexibility after the data has become immutable?
What the original adds
The source gives implementation-level details for five optimizations, including Rust layout mechanics, allocator effects under jemalloc, DNS owner-name handling, and before/after benchmark and production figures.
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.