You run a CDN in front of an API and the hit rate is poor because responses declare several request headers in the HTTP Vary header. How would you decide which headers belong in the cache key, and how would you normalize them?

## Frame it as cache-key design The cache key is a product space. Primary key (URL) times every header named in `Vary`, each contributing its cardinality. Two encodings times five languages times a device class of three is thirty objects per URL — thirty misses to fill, thirty entries competing for storage, and thirty chances that the object a given user needs has been evicted. Hit rate does not fall linearly with the number of headers; it falls with the product of their cardinalities. So the work is not 'have fewer Vary headers', it is 'make each axis as small as it can be while staying correct'. ## Step 1 — measure before changing anything Pick the hottest URLs and pull, per URL: the `Vary` value, the number of distinct stored variants, hit rate, and origin request rate. Most CDNs expose variant counts or at least a cache-status header you can bucket. The usual finding is one dominant offender — `Cookie`, `User-Agent`, or a raw unnormalized `Accept-Encoding` — producing thousands of variants while the other axes contribute two or three each. ## Step 2 — classify each header For every name in `Vary`, ask in order: 1. **Does the response actually differ along this axis?** Framework middleware adds headers reflexively — session middleware appending `Cookie`, CORS middleware appending `Origin` to responses with a constant wildcard. If the bytes never change, delete the axis. This is usually the single biggest win and costs nothing. 2. **How many distinct outputs can the origin actually produce?** This is the true cardinality. If the origin only ever emits identity or gzip, then `Accept-Encoding` has cardinality two no matter how many distinct strings clients send. 3. **Can the axis move into the URL?** A path or query parameter is a better place for coarse, stable variation: `/v1/pricing?country=de`. It is visible in access logs, purgeable per value, shareable as a link, and testable. `Vary` is for axes that must stay invisible to the client — compression, CORS reflection. ## Step 3 — normalize at the edge Normalization means rewriting the request header, before the key is computed, to a canonical token drawn from that true cardinality: - `Accept-Encoding`: parse, ignore q-values and ordering, emit `br` if supported and produced, else `gzip`, else empty. - `Cookie`: never key on it raw. Derive one bit or one small enum — presence of a session cookie, an experiment bucket — into a dedicated header such as `X-Auth-State` and vary on that. - `User-Agent`: never key on it raw either; bucket to `mobile|tablet|desktop`, or better, stop varying and serve responsive content. - `Accept-Language`: map to the languages you actually publish, with a fallback, so `de-AT,de;q=0.9,en;q=0.8` becomes `de`. - `Origin`: leave as-is when reflecting from a bounded allowlist — cardinality equals the allowlist size, which is small — but reject non-allowlisted origins early so they collapse to one variant. Normalization has to be **deterministic and total**: every possible input maps to one of the canonical tokens, including missing and malformed values, otherwise attacker-controlled or exotic headers reintroduce unbounded cardinality. A header you key on that a client can set freely is also a cache-flooding vector: someone can push a hot object out of storage by cycling values. ## Step 4 — handle what cannot be normalized Whatever is left — genuinely per-user representations — should not be in a shared cache at all. Options in preference order: mark it `private` or `no-store`; split the page into a highly cacheable shell plus a small uncacheable personalized fragment fetched separately; or move personalization to the client. Trying to make per-user content shareable through clever keys is where cross-user data leaks come from. ## Step 5 — make it a contract, not a habit Centralize the policy in the edge configuration rather than trusting each service's headers, and add tests: assert that responses with a reflected `Access-Control-Allow-Origin` include `Origin` in `Vary`, that no production response carries `Vary: Cookie` or `Vary: User-Agent` unless explicitly waived, and that compressible content carries `Vary: Accept-Encoding`. Then watch variant count per URL as a first-class metric alongside hit rate — hit rate alone hides key explosion, because the CDN happily reports high hit rates on the subset of objects that do get reused while the origin still carries the load. ## The tradeoff to state out loud Every normalization is a deliberate loss of fidelity: bucketing `Accept-Language` means some users get a coarser language match; collapsing `User-Agent` means you stop serving device-specific markup. That is the trade — you are buying origin protection and tail latency with a small amount of personalization. Decide it explicitly per endpoint rather than letting middleware defaults decide it for you.