Cloudflare’s engineering organization says it saved roughly 100 terabytes of memory in the 1.1.1.1 resolver cache, a claim this article cannot yet verify. What can be verified is more useful anyway: the levers that produce that kind of saving, eviction and admission policy, entry layout, TTL discipline, are documented in the cache software you already run, and most operators have never touched them.
Did Cloudflare really save 100 TB in the 1.1.1.1 cache?
The 100 TB figure comes from a Cloudflare engineering post observed on 2026-08-28, but no public technical detail on the 1.1.1.1 cache is available yet, so both the headline number and its mechanism remain [unverified] as of this writing.
That distinction matters more than the number. A cache memory saving at resolver scale can come from at least three different interventions, and they imply very different things for anyone copying the result. Tightening the eviction policy changes which entries leave. Adding admission control changes which entries get stored at all. Reworking the entry layout shrinks every record regardless of policy. A headline that says “100 TB saved” without naming the mechanism is marketing arithmetic, not engineering guidance: nobody outside Cloudflare knows which lever did the work, or whether it was all three.
What is verifiable is the scale at which the claim is being made. Cloudflare describes a network operating in 335+ cities, within 50 ms of 95% of the world’s population, with 500 Tbps of advertised capacity. A resolver fleet at that footprint is plausibly the highest-QPS caching system in regular operation, which means even a single-digit percentage reduction in per-entry overhead compounds into fleet-level numbers that look absurd next to anything a single operator will ever run.
The company’s self-reported reach also deserves the usual discount. Cloudflare’s site claims 20% of all websites are protected by its network; W3Techs independently measured 21.3% as of January 2026. Those two figures happen to agree, which is unusual, but the general pattern holds: vendor coverage and performance numbers are self-reported until an outside party measures them. Apply the same reflex to “we saved 100 TB.”
Where does resolver cache memory actually go?
A resolver’s cache memory is the product of three terms: how many entries are live, how large each entry is, and how much bookkeeping the cache spends per entry to know when to expire and evict it. Optimization means attacking one of those terms without degrading hit rate.
Entry count is the term operators think about first, and it is the one the TTL system already partially manages. Every DNS answer arrives with a time-to-live set by the record owner, and a resolver that honors TTLs is running a cache where the admission window is dictated externally. Popular records churn constantly; the long tail of one-off lookups (tracking domains, generated subdomains, typos) occupies memory while contributing almost nothing to hit rate. At public-resolver QPS, that tail is enormous, and it is the first place memory goes to die.
Entry size is the second term. DNS answers are small, but the stored representation is rarely just the wire-format record. A resolver keeps the answer, its metadata, expiry state, and whatever index structures let it find the entry in microseconds. In most real cache implementations the overhead per entry, hash table slots, expiry heap nodes, linked-list pointers, allocation rounding, is a substantial fraction of the payload itself. Shrinking the per-entry footprint by even tens of bytes multiplies across hundreds of millions of live entries, which is exactly the arithmetic that produces fleet-level terabyte claims from boring-sounding layout work.
The third term is policy overhead: what the cache spends to decide what leaves. Default LRU is cheap to maintain but blind to frequency, so a record queried once an hour and a record queried a thousand times a second get the same treatment once they are both in. Every alternative policy trades bookkeeping cost for better eviction decisions, and at resolver QPS that bookkeeping sits on the decision path itself, which bounds how much of it any implementation can afford.
These are the three candidate mechanisms for the Cloudflare result. What does not require the post is the observation that all three levers exist in commodity cache software, which is where the useful part of this story lives for everyone else.
What eviction levers does Redis already give you?
Redis ships multiple eviction policies plus key expiration and hash-field expiration, per the project’s repository, which means the policy surface an operator needs to cut memory without buying RAM is already compiled into the binary sitting in production.
The repository names the capability without enumerating the policies, so the citable record here is the shape of the menu rather than its contents: multiple policies exist, and which one your instance runs is a configuration value. If you have never changed maxmemory-policy, you are running whatever the default was when the instance was provisioned. Confirm that before anything else.
LRU versus LFU is the comparison worth understanding, because it is the same trade the resolver case makes. LRU assumes recency predicts reuse. For workloads with scans, batch jobs, or one-time reads interleaved with a hot working set, that assumption fails: a single nightly report can flush the cache of the records that actually serve traffic. LFU tracks access frequency instead, so the one-hit wonders from the batch job never displace the hot set. The cost is that LFU needs per-key frequency state and has its own pathologies, notably aging: a key that was hot yesterday and never again can hold a high counter and resist eviction. Whether an implementation compensates for that, and how, is exactly the kind of detail to read in the policy documentation rather than the marketing page.
One further property matters for anyone benchmarking this on their own telemetry: expiration and eviction are separate systems. Key expiration and hash-field expiration let you bound residency by time, which caps the worst-case memory of entries that policy alone would keep. Well-tuned tiers use both: TTLs as the ceiling, an eviction policy as the pressure valve.
Redis itself is an in-memory key-value database used as a distributed cache and message broker, with optional durability. The “in-memory” part is why this lever matters: every byte is DRAM, priced like DRAM. The eviction config is the cheapest capacity planning tool in the stack, and the first thing to establish is whether anyone has ever set it.
How does the same problem look across three cache tiers?
The hit-rate-versus-memory tradeoff is identical in shape across DNS resolvers, in-memory key-value stores, and CDN edges; what changes is entry size, who sets the TTL, and how skewed the popularity distribution is, which determines which lever pays.
A public DNS resolver caches small entries whose TTLs are set by millions of independent record owners, under a popularity distribution with an extremely heavy tail. The operator cannot change the TTLs, so the available levers are admission (refuse to cache entries unlikely to be re-queried), eviction policy, and entry layout. Negative caching, remembering that a name does not exist, adds a second class of entries with its own TTL semantics. This is the tier Cloudflare operates, and the tier where a one-byte saving per entry is a fleet-level event.
Redis fronting a database inverts the control surface. The operator chooses both the TTLs and the data model, entries range from session tokens to serialized objects, and the popularity distribution is whatever the application produces. Here the cheapest lever is often not policy at all but TTL discipline: keys written without expiration accumulate forever, and a fail-closed eviction setting turns that accumulation into an outage rather than a slow leak. Policy selection matters most when the workload mixes a stable hot set with scan-like traffic, which describes most applications that have a batch job anywhere in them.
CDN edges operate on large objects, where a content delivery network is a geographically distributed network of proxy servers and corresponding data centers and each node makes its own retention decisions. The scale reference point: King uses Amazon CloudFront to deliver hundreds of terabytes of content daily, spiking to half a petabyte or more on game launches. At object sizes measured in megabytes, per-entry metadata overhead is irrelevant and the entire game is admission and eviction: whether to store an object at a given edge at all, and when to drop it. Same problem, three orders of magnitude of entry size, and the lever that matters moves from layout to admission as entries grow.
The transferable insight across all three is that “cache” describes a decision system, not a storage system. Every tier is continuously answering two questions, store this or not, drop this or not, and the defaults shipped in 2010 answer both lazily.
When does memory growth stop tracking hit rate?
Memory requirements decouple from hit rate when the marginal entry you are storing contributes almost nothing to hits, which happens in any workload where popularity is skewed, because caching the hot head of the distribution is cheap and caching the tail costs effectively unbounded memory for near-zero benefit.
This is the arithmetic underneath every cache-sizing rule of thumb. In a Zipf-like distribution, a small cache holding the most popular fraction of keys captures the large majority of requests; doubling memory after that buys progressively smaller hit-rate increments. Operators experience this as a comfortable plateau followed by a wall: the cache serves 95% of requests from RAM that has not grown in a year, and then traffic doubles, the tail doubles with it, and the capacity plan says to double RAM to hold a hit rate that was never coming from the tail anyway.
Admission control is the lever that breaks the coupling. If the cache refuses to store entries it predicts will never be re-queried, one-hit wonders, first-seen names, objects requested once per day, memory stops growing with the tail while hit rate barely moves, because the tail was contributing misses regardless. The resolver version of this is declining to cache names with no reuse signal; the Redis version is LFU-flavored policies and short TTLs on unproven keys; the CDN version is not writing an object to an edge disk until its second request. The interesting possibility in the Cloudflare story is that admission control of this kind now runs in production in one of the highest-QPS caches operating. That moves the burden of proof: an operator still running default LRU on a memory-bound tier increasingly needs to justify that choice in review rather than inherit it.
The counterweight is that admission policies have their own failure mode: a mispredicted entry that would have been hot becomes a miss every time, and the upstream database or origin absorbs the difference. The correct evaluation is never memory alone. It is memory, hit rate, and origin load, measured together, on your traffic.
How do you verify a cache-savings claim before copying it?
Verify a vendor cache-savings claim by extracting five things from the primary source: the named mechanism, the baseline it improved on, whether the number is peak or steady-state, whether it is per-node or fleet-wide, and whether hit rate was reported alongside memory. Any claim missing two or more of those is a press release, not a result.
The mechanism question is the first one to demand: eviction, admission, layout, or some combination, stated precisely enough to reproduce. “We optimized the cache” is not a mechanism. “We replaced LRU with a frequency-adaptive policy and it cut resident entries by X% at constant hit rate” is.
Baseline matters because savings against a strawman are free. A result measured against default configuration tells you the vendor read their own documentation; a result measured against a tuned baseline tells you something real. Peak versus steady-state is where numbers inflate: a change that lowers the allocation ceiling looks like a huge saving against a peak that occurred twice, while steady-state residency barely moved. Per-node versus fleet is where numbers impress: multiply anything by enough points of presence and it becomes terabytes.
Independent measurement is the last check, and it is the habit the W3Techs comparison is good for. Cloudflare’s marketing pages report 234 billion threats blocked daily and a fifth of the web behind the network; outside measurement put the web share at 21.3%. Close agreement there does not mean every number the company publishes is audited, and an engineering blog post, whatever its technical merits, is also a communications artifact. None of that makes the result false. It means the reader’s job is unchanged: find the mechanism, find the baseline, then decide.
What’s the practical verdict?
Treat the 100 TB claim as an unverified headline; the evidence-backed lever available to you today is policy selection on the cache tier you already run, measured against your own hit-rate and memory telemetry before any RAM purchase.
Concretely: if you operate Redis in front of a database and have never changed the eviction configuration, you are running the default, and the fix is a config change plus a week of measurement, not a hardware order. If you operate an on-prem resolver or a CDN-like edge, the same audit applies with the tier-appropriate lever: TTL discipline and policy for small entries, admission for large ones. And if the Cloudflare mechanism turns out to be learned admission or adaptive eviction running at resolver QPS, the durable consequence is that default LRU stops being a defensible neutral choice and becomes a position you hold on purpose, with data.
The strongest limitation on all of this is the missing primary source: no public technical detail on the 1.1.1.1 cache is available yet, so nothing above describes what Cloudflare actually did; it describes what a claim of that shape would have to mean and how to test it. There is a second limitation worth keeping even after the post surfaces: techniques proven on an anycast fleet spanning 335+ cities may not transfer to a single Redis node or a two-server on-prem resolver, because the traffic mix, the tail, and the failure economics are different animals. Copy the methodology, which is mechanism, baseline, hit rate alongside memory. Do not copy the number.
Frequently Asked Questions
Does the 100 TB saving apply to a single Redis node or an on-prem resolver?
No, the figure is a fleet-wide aggregate across Cloudflare’s 335+ city anycast network, not a per-node metric. A single Redis node or two-server on-prem resolver operates under different traffic mixes and failure economics, so the absolute terabyte count does not transfer. Operators should treat the number as a scale reference, not a sizing target for local infrastructure.
How does LFU eviction differ from LRU in handling batch job traffic?
LRU evicts based on recency, so a single nightly batch scan can flush the hot working set of frequently accessed keys. LFU tracks access frequency, preventing one-hit wonders from displacing stable hot data. However, LFU carries a risk of ‘aging,’ where keys that were hot in the past but are no longer active retain high frequency counters and resist eviction, potentially holding memory longer than necessary.
What specific metrics must be captured before changing maxmemory-policy in production?
Operators must snapshot current hit rates and memory high-water marks before applying changes. The evaluation must measure memory, hit rate, and origin load together, because a policy change that reduces memory but increases origin database load shifts the cost downstream. Running the candidate policy on a replica or shadow instance for at least one week of traffic is required to observe these downstream effects before promoting the config change.
Why is admission control more critical for CDN edges than for DNS resolvers?
CDN edges cache large objects, often measured in megabytes, where per-entry metadata overhead is negligible compared to the payload size. In this tier, the primary lever is admission: deciding whether to store an object at all until its second request. DNS resolvers, which cache small entries, can also benefit from entry layout optimization, but CDN edges rely almost entirely on admission and eviction policies to manage disk and memory constraints.
What is the primary risk of relying on vendor-reported cache savings figures?
Vendor claims often conflate peak memory usage with steady-state residency and aggregate fleet totals with per-node performance. For example, Cloudflare’s self-reported web share of 20% aligns closely with W3Techs’ independent measurement of 21.3%, but this agreement does not guarantee that performance metrics like memory savings are independently audited. Operators must verify the mechanism, baseline, and whether the number represents a snapshot or a sustained specification.
