CONCEPT Cited by 1 source

Cache-variant explosion¶

Cache-variant explosion is the cartesian-product storage-pressure + hit-rate-drop phenomenon that occurs when a cache key is extended with new dimensions. Each new dimension multiplies the number of distinct variants the cache can hold for a single URL. Adding one dimension with N possible values turns K variants into K×N variants.

Canonical 2026 instance: Cloudflare Shared Dictionaries Phase 1 passthrough extends cache keys to vary on both Accept-Encoding and Available-Dictionary so delta-compressed responses are served correctly per client. See sources/2026-04-17-cloudflare-shared-dictionaries-compression-that-keeps-up-with-the-agent.

The mechanism¶

Cache keys are conceptually (URL, Accept-Encoding, Available-Dictionary, …). For a single URL served during a mid-deploy window, the edge can hold:

(url, gzip,             none)         — legacy clients
(url, br,               none)         — Brotli-capable, no dict
(url, zstd,             none)         — Zstd-capable, no dict
(url, dcz,              hash_v1)      — client has v1 as dict
(url, dcz,              hash_v2)      — client has v2 as dict
(url, dcz,              hash_v3)      — client has v3 as dict
…

With K unique content versions in flight × M client Accept-Encoding profiles × N dictionary versions each client may have cached, the variant count grows multiplicatively. During active deployment, many clients are in-flight with stale dictionary hashes, so the edge must either:

Materialise each variant on demand (compute cost per miss).
Pre-materialise all expected variants (storage cost × variant count).
Some hybrid.

Why it matters¶

Two effects that combine badly:

Storage pressure: edge storage is finite. More variants per URL means either fewer URLs can be kept warm, or more variants must be evicted.
Hit rate drop: the same aggregate cache-request volume is now split across more keys. Any individual variant sees fewer hits, so the variant cache hit rate drops even though the URL cache hit rate stays the same. Clients whose variant is cold pay the origin-fetch / on-demand- compress cost.

Both effects are temporary — once a deploy window closes and clients converge onto the current dictionary version, the variant count collapses back — but every deploy cycle repeats the transient.

Why the CDN is the right place to absorb it¶

Cloudflare's 2026-04-17 shared-dictionaries launch names this explicitly: "responses vary on both encoding and dictionary hash, so every dictionary version creates a separate cache variant. Mid-deploy, you have clients with the old dictionary, clients with the new one, and clients with none. Your cache is storing separate copies for each. Hit rates drop, storage climbs, and the dictionaries themselves have to stay fresh under normal HTTP caching rules."

Origin caches (Nginx, Varnish, application-level caches) have to solve this themselves. CDN-level implementation amortises the variant storage across many customers and many POPs — a concrete instance of edge-managed protocol complexity.

Sibling concepts¶

Vary: header semantics — the HTTP primitive that declares which request headers a cache must incorporate into the cache key. Shared-dictionary compression effectively requires Vary: Accept-Encoding, Available-Dictionary on the response.
Cache fragmentation — similar effect from user-segmentation keys (A/B test cohort, geolocation, personalisation). Same cartesian-product shape.

Seen in¶

sources/2026-04-17-cloudflare-shared-dictionaries-compression-that-keeps-up-with-the-agent — Cloudflare names cache-variant explosion as part of the coordination cost that motivates moving shared-dictionary implementation from origin to CDN.