The reading room · Digna Legi
How we could save petabytes of cache storage with Zstandard and Pingora
/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 post reports a prototype and controlled tests, not a fully deployed fleet-wide outcome.
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
Cloudflare’s cache prototype pays compression once, then reuses smaller internal representations while keeping client-visible bytes unchanged for eligible text.
AI brief · Checked against source text
The main idea
Cloudflare’s prototype stores eligible uncompressed text assets in zstd form inside the cache, then decodes them before serving clients. The mechanism works because encoding is paid once at cache fill, while smaller on-disk and inter-tier representations keep saving space and bandwidth each time the object is reused. The claimed trade is favorable only for tested eligible text, not for already-compressed media or every internet object.
Go a little deeper
Representation is an internal contract
The useful distinction is between what the client receives and how the cache stores the object. Cloudflare keeps the client-facing response identical by decoding before delivery, while changing the internal disk and tier-transfer representation. That makes compression a cache architecture decision rather than a content negotiation feature, with metadata preventing repeated encoding across cache layers.
Eligibility protects the trade
The prototype’s value depends on refusing work that is unlikely to pay back. Images, video, and fonts are mostly already compressed, so recompressing them wastes CPU. The chosen boundary is narrower: successful unencoded compressible text with known length at least 4 KiB, excluding range requests, unknown bodies, precompressed responses, active upstream compression, and binary content.
Popularity filtering failed for a structural reason
A tempting policy was to compress only hot content, because frequently reused assets seem likelier to repay fill-time encoding. The prototype found the opposite tradeoff: decoding happens on every serve, so restricting compression to the hottest assets sacrifices much of the storage gain without proportionally reducing CPU. A simple size-and-type rule performed better under the tested assumptions.
Tiered caching multiplies the benefit
The gain is not only local disk density. When a lower cache tier misses but an upper tier has the object, the compressed representation travels between data centers and remains compressed until the client-facing hop. That means one internal representation reduces both eviction pressure and backbone transfer for reused eligible objects.
A case from the article
The controlled cache campaign
Cloudflare tested two deliberately compressible assets of about 195 KiB and 272 KiB across 10 cache servers, with one half of the campaign using Tiered Cache and the other half disabling it. Varying cache keys forced specific paths, letting the team check cache misses, hits, fills, and tier transfers while confirming where encoding and decoding happened.
How the case is made
The case is made through a prototype, controlled cache-path testing, per-request log/metric/trace correlation, and a million-request performance campaign.
Where the idea has limits
The measured roughly 2.8x compression came from deliberately compressible assets; the source explicitly says a broader corpus is needed before treating that ratio as fleet-wide.
A question to take away · from Digna Legi
Where else is a system paying repeated storage or transfer costs because it preserves an external representation internally?
What the original adds
The source adds concrete implementation boundaries: metadata marks zstd storage, decoding occurs before client delivery, Tiered Cache transfers compressed objects, and eligibility excludes tiny, binary, range, unknown-length, precompressed, and actively compressed responses.
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.