Cloudflare Quietly Saved 100TB of RAM With One DNS Trick
In this article
Bottom line: Cloudflare's engineering team found that its 1.1.1.1 resolver was storing millions of near-identical DNS answer sets separately in memory, because every cached record was tied to its own domain name even when the underlying IP data was identical.
By deduplicating and sharing those repeated record sets across cache entries instead of copying them, the team cut memory consumption across its DNS caching fleet by roughly 100 terabytes.
No new hardware, no funding round, no rewrite — just a smarter way to store the same bits once instead of a million times.
I've spent a decade telling junior engineers that "premature optimization is the root of all evil." Cloudflare just made me eat that line for breakfast.
Because the fix that saved them 100TB of RAM wasn't a clever new caching algorithm or a hardware upgrade.
It was someone finally asking an obvious question that everyone had walked past for years: why are we storing the same answer twice?
Why This Is Actually a Big Deal
Here's the thing about DNS that most people — even most developers — never think about.
Every time you type a URL, your device asks a resolver "what's the IP address for this name?" Cloudflare's 1.1.1.1 answers something like trillions of these questions a day, for one of the largest public resolvers on the planet.
To do that fast, you cache answers. That's DNS 101 — cache the response, respect the TTL, don't hammer the authoritative nameserver for every single request. Nothing revolutionary there.
But here's what nobody talks about: the internet is mostly duplicates. Millions of domains sit behind the same handful of CDNs, the same load balancers, the same shared hosting IPs.
When you resolve `random-startup-42.com` and `another-startup-99.com`, there's a decent chance they both eventually point at the same handful of IP addresses, especially once you factor in how much of the web now runs through a small number of infrastructure providers — Cloudflare included.
A resolver cache that treats every domain name as needing its own independent, fully-copied record set is paying a storage tax on redundancy it doesn't need to carry.
Multiply that inefficiency across billions of cached entries, replicated across every core, every machine, every point of presence in a global network, and you get exactly the kind of quietly enormous waste that never shows up on a dashboard — until someone goes looking.
Everyone's Celebrating the Number. That's the Wrong Takeaway.
The Hacker News thread on this is full of people marveling at "100 terabytes," and sure, that's a satisfying headline figure.
But if you stop there, you're missing the actual lesson, and it's a more uncomfortable one for most engineering orgs than "big number go down."
The real story isn't that Cloudflare found a clever trick.
It's that a company running one of the most scrutinized, most optimized pieces of internet infrastructure on Earth had a 100-terabyte inefficiency sitting in production, unnoticed, for who knows how long.
Think about what that implies. This isn't a scrappy startup with a duct-taped backend.
This is Cloudflare — a company whose entire business is "we make the internet faster and cheaper to run than you can yourself." If an inefficiency of this size can hide inside their DNS layer, it tells you something uncomfortable about the assumption baked into most infrastructure teams: that scale and maturity mean the low-hanging fruit is gone.
It isn't.
It's just further up the tree, disguised as "the way things have always worked." Nobody questioned the per-name storage model because it was never wrong — it worked fine, resolvers resolved, latency was low, customers were happy.
It just wasn't examined for years because there was no incentive to look. That's the pattern worth sitting with, way more than the number itself.
The Redundancy Blindspot Framework
If you want a mental model for where these hundred-terabyte-sized inefficiencies hide in your own systems, I'd offer this: most infrastructure waste isn't caused by bad code.
It's caused by structural assumptions nobody revisits. I call it the Redundancy Blindspot, and it shows up in three stages.
1. The Reasonable Default
Someone builds a system with a sensible-at-the-time design: cache entries keyed by domain name, each with its own copy of the record data.
It's simple, it's obviously correct, and at launch scale, the redundancy costs nothing measurable. This is the default that becomes invisible the moment it works.
2. The Silent Multiplication
The system scales. Every new domain, every new query pattern, every new point of presence multiplies the original design decision — without anyone re-deriving whether the assumption still holds.
At small scale, storing full copies per key costs kilobytes.
At trillions of queries and millions of distinct names sharing overlapping answers, that same assumption compounds into actual physical server racks worth of RAM, quietly, gradually, and untracked, because nothing ever "broke."
3. The Deliberate Audit
Somebody — not automated tooling, not an alert, a human being with curiosity — asks "wait, how much of this is actually unique data?" That question is the entire unlock.
Once you know a huge share of your cached records are duplicates of each other, the fix (deduplicate, reference-count, share underlying storage) is almost boringly simple engineering.
The hard part was never the fix. It was noticing there was something to fix.
This pattern isn't unique to DNS. It's in your database indexes, your logging pipelines, your container images, your feature flags nobody's cleaned up in three years.
The Redundancy Blindspot exists anywhere a system scaled past the point where its founding assumptions were ever re-examined.
What This Actually Means for Your Job
If you're an infrastructure or platform engineer, this should reframe how you think about "done" systems.
Systems that have been running fine for years, without incident, are exactly the ones most likely to be carrying this kind of hidden cost — because stability is precisely what makes them go unexamined.
If you're at a company running any kind of high-cardinality cache — DNS, CDN edge caches, session stores, feature-flag evaluation caches — go find out today how much of what you're storing is actually unique versus duplicated across keys.
You may not find 100TB. You might find 4% savings. But at cloud pricing, 4% of a memory-heavy fleet is real money, and it's money you're currently paying for nothing.
If you're a manager or a founder, the lesson is about where you point your best engineers.
Everyone wants to hire for "build the new thing." Far fewer companies systematically reward the engineer who spends two weeks asking "why does this cost what it costs?" on a system that already works.
Cloudflare's save didn't come from a roadmap item.
It came from someone with the latitude to go digging in a place nobody had assigned them to look.
If your org doesn't create space for that kind of unassigned curiosity, you are structurally guaranteed to be carrying your own invisible 100-terabyte problem right now, in some part of your stack you haven't thought about since it launched.
And if you're just tech-curious and none of this is your job — this is worth knowing anyway, because it's a preview of where a huge amount of the AI infrastructure buildout is headed next.
Every hyperscaler racing to add GPU capacity is also quietly sitting on years of "reasonable defaults" in their storage and caching layers that nobody has re-audited under today's scale.
The next real capacity win for a lot of these companies won't be a new data center. It'll be someone asking Cloudflare's question about their own stack.
The Bigger Truth Hiding in a DNS Cache
There's something almost poetic about the fact that the fix here was, at its core, about not storing the same truth twice.
We live in an industry obsessed with "more" — more compute, more model parameters, more data centers, more GPUs.
Cloudflare just proved, at a scale most companies will never touch, that "less redundant" can beat "more capacity" outright.
That's a harder sell than a keynote about a new data center, because it requires admitting the old design wasn't as efficient as everyone assumed.
It requires the kind of institutional humility that most engineering orgs, mine included, aren't great at practicing on systems that "already work."
So here's the question I can't shake: how much redundant, un-audited, quietly-multiplying waste is sitting inside the system you're responsible for right now — not because anyone did anything wrong, but because nobody's had the reason, or the permission, to go looking?
