Skip to content

CONCEPT Cited by 2 sources

Cache-variant explosion

Definition

Cache-variant explosion (a.k.a. cache fragmentation) is the failure mode in which a single cacheable resource is split into many cache entries — one per distinct cache-key value — most of which receive too little traffic to stay hot, even though many of the stored bodies are byte-for-byte identical. It is the efficiency cost of keying a cache on high-cardinality inputs, most often the request headers named by Vary during content negotiation.

The pathology: a cache can be perfectly correct and almost permanently cold. Identical responses scatter across low-traffic entries that consume capacity, evict one another, drag down the concepts/cache-hit-rate, and send more requests to origin. Eviction removes cold entries but cannot merge them just because the bodies are identical. (Source: sources/2026-09-22-cloudflare-we-just-shipped-support-for-the-ugliest-part-of-http-vary)

Why it happens: input cardinality ≫ output cardinality

Applications produce a small, finite set of representations from an enormous set of possible request values. An origin serving only English, French, and German maps thousands of distinct Accept-Language strings (different orders, regional tags, quality values, even whitespace) onto three responses — but a cache comparing raw header bytes cannot know that, so it stores each raw string as its own variant.

The explosion is combinatorial across fields:

  • 10 values on one field → 10 variants.
  • 10 values across three fields → 1,000 variants.
  • Real headers have far higher cardinality still: User-Agent values are numerous, Cookie can be unique per visitor, and preference headers differ in ordering, formatting (spaces and tabs matter), and quality values.

An analysis of >120M responses across ~50,000 sites found nearly 3,000 varying on ≥4 fields, some on 10, 23, or 47 — each additional field multiplying the potential variant count.

This is cardinality blowup applied to cache keys rather than to observability labels: the same "one dimension too many and the key space detonates" dynamic.

Controls

Three levers, from most to least cache-preserving:

  1. Normalize the high-cardinality input to its canonical, low-cardinality form before variant selection — lowercase, sort by quality value, strip parameters, fold regional language tags to base languages — so equivalent requests collapse onto one entry. The recommended default for negotiation headers.
  2. Passthrough (key on raw bytes) only when the value set is genuinely small and controlled and the exact value changes the response. Incidental differences (compact,full vs Compact,full vs compact, full) each mint a new key.
  3. Bypass cache for personalized / unbounded headers (Cookie, User-Agent) where no reuse is possible anyway.

Deliberate high-cardinality variation can be safe when the values are controlled and every component agrees on their meaning — e.g. a CDN injecting a bounded geographic-region value to partition content predictably. Without those constraints, the cache fragments into variants it may never reuse. (Source: sources/2026-09-22-cloudflare-we-just-shipped-support-for-the-ugliest-part-of-http-vary)

The same explosion arises without Vary when the cache key is extended to carry encoding dimensions. Cloudflare's Shared Dictionaries work extends the cache key to vary on both Accept-Encoding and Available-Dictionary, so mid-deploy the edge can hold gzip / Brotli / zstd / dcz-against-v1 / dcz-against-v2 / raw variants of one URL — storage pressure growing with the dictionary-variant cardinality. (Source: sources/2026-04-17-cloudflare-shared-dictionaries-compression-that-keeps-up-with-the-agent)

Seen in

Last updated · 766 distilled / 2,225 read