CDNs: Cache Keys, Edge Routing, and Origin Shielding

The core idea: a CDN is a distributed HTTP decision layer: it routes users to edge locations, decides whether a request matches cached content through a cache key, and protects the origin only when that key and the cache policy describe the real representation.

Core Insight

Imagine a shop launch where a new product image is requested by users in Madrid, Sao Paulo, and Tokyo. Without a CDN, all those users may fetch the image from the same origin region. Latency is high, and the origin handles the same bytes again and again. With a CDN, the first request near each region can fetch from origin, then later nearby users receive the image from an edge cache.

That sounds simple until the URL becomes:

https://static.shop.test/products/42/hero.jpg?width=800&utm_campaign=launch

Should utm_campaign change the cached object? Probably not. Should width=800 change it? Yes, if the image service returns a different representation for each width. Should a logged-in discount page be cached the same way as a public image? No. The CDN can reduce latency only when it knows which requests are equivalent and which requests must stay separate.

The central mechanism is the cache key. A cache key is the identity the CDN uses to decide whether a request matches an object it already has. It is usually built from pieces such as scheme, host, path, query string, selected headers, and sometimes device or language signals. Two requests with the same key are treated as asking for the same cached representation. Two requests with different keys are treated as different objects.

The trade-off is global latency reduction versus correctness and origin pressure. A broad cache key can improve hit ratio but risk serving the wrong representation. A narrow cache key can protect correctness but fragment the cache until every tiny variation becomes a miss. A good CDN design is not "cache everything." It is "make the identity of cacheable content explicit, route requests to useful edges, and shield the origin from repeated work without hiding freshness or personalization mistakes."

The Pieces in a CDN Path

A CDN, or content delivery network, places edge servers close to users. A user reaches the CDN through DNS steering and anycast or provider-specific routing. The edge receives the HTTP request, checks cache policy, and either serves a stored response or forwards the request toward an origin.

A simplified path looks like this:

browser
-> DNS chooses or discovers a nearby CDN edge
-> edge receives HTTPS request
-> edge computes cache key
-> cache hit: edge returns stored response
-> cache miss: edge fetches from origin or origin shield
-> edge stores response if policy allows
-> edge returns response to client

The origin is the authoritative backend for the content. It may be an object store, an image resizing service, a web application, or another load balancer. The CDN is not the source of truth. It is a distributed layer that can reuse previously fetched responses according to HTTP headers and CDN-specific policy.

A cache hit means the edge found an object for the computed key and judged it usable. A cache miss means the edge did not have a usable object and had to go upstream. A stale response is an object whose freshness lifetime has expired but may still be used under specific policies such as revalidation, stale-while-revalidate, or fail-open behavior during origin trouble.

The CDN also performs edge routing. "Edge" is not one machine. A provider may have many points of presence. Traffic can be routed by resolver location, anycast network behavior, health, load, or regional policy. That routing affects latency and failure isolation. A user in Tokyo should not normally fetch a static image from a Virginia origin if a healthy Tokyo or nearby edge already has it.

Origin shielding adds another layer. Instead of letting every edge miss go directly to the origin, the CDN can send misses through a selected shield location:

many edges -> one shield cache -> origin

If ten edge locations miss the same object at the same time, the shield can reduce duplicate origin fetches. It becomes a second-level cache and a choke point for origin traffic. That improves protection, but it also adds another hop and another place where cache policy must be understood.

Cache Keys Decide What "Same" Means

Return to the product image. The origin can produce multiple sizes:

/products/42/hero.jpg?width=400
/products/42/hero.jpg?width=800
/products/42/hero.jpg?width=1200

If the CDN cache key ignores the query string entirely, all three requests may map to the same cached object:

bad key:
host=static.shop.test path=/products/42/hero.jpg

The first user asks for width=400, the edge stores the 400px image, and the next user asking for width=1200 receives the wrong size. The cache hit ratio looks good because many requests collapse into one object, but correctness is broken.

If the key includes the full query string, correctness may improve:

better key:
host=static.shop.test path=/products/42/hero.jpg query=width=800

But now add analytics parameters:

?width=800&utm_campaign=launch
?width=800&utm_campaign=email
?width=800&utm_source=partner

If the full query string is part of the key, those become separate cached objects even though the bytes are identical. The cache fragments. More users miss, more requests reach origin, and the CDN does less useful work.

The better policy is to include representation-changing inputs and exclude tracking noise:

key includes:
host, path, width

key ignores:
utm_campaign, utm_source, session tracking parameters

Headers can matter too. If the origin returns different content for Accept-Encoding, Accept-Language, or device hints, the CDN either needs to vary the cache key or normalize the variants intentionally. HTTP's Vary response header expresses that a response varies by selected request headers. CDN products often add their own controls because high-cardinality headers can explode the cache.

Cookies and authorization headers are especially sensitive. A request with Authorization or user-specific cookies should usually bypass shared cache or use a carefully partitioned private mechanism. A CDN serving one user's account page to another user is not a caching optimization. It is a security incident.

The practical rule is:

cache key = public representation identity
not necessarily the full URL
not user identity unless the cache is explicitly private or partitioned

Worked Path: From Miss Storm to Shielded Cache Hit

The shop launches a new hero image:

URL: /products/42/hero.jpg?width=800&utm_campaign=launch
origin: image-service.internal
cache policy: public, max-age=3600
key policy: host + path + width
shield: enabled in eu-west

At 09:00, a user in Madrid requests the image. The Madrid edge computes:

host=static.shop.test
path=/products/42/hero.jpg
width=800

The object is not in the Madrid edge cache, so the request is a miss. Because shielding is enabled, the Madrid edge asks the shield cache rather than the origin directly. The shield also misses and fetches from the image service. The image service returns:

HTTP/1.1 200 OK
Content-Type: image/jpeg
Cache-Control: public, max-age=3600

The shield stores the response under the key. The Madrid edge stores the response too, then returns it to the user.

At 09:01, another Madrid user requests:

/products/42/hero.jpg?width=800&utm_campaign=email

The edge computes the same key because utm_campaign is ignored. This is a hit. The origin is not touched.

At 09:02, a Tokyo user requests the same width. The Tokyo edge misses locally, but the shield already has the object. Tokyo fetches from the shield instead of origin. The origin is still protected.

The path is now:

Madrid first request -> edge miss -> shield miss -> origin fetch
Madrid next request  -> edge hit
Tokyo first request  -> edge miss -> shield hit
Tokyo next request   -> edge hit

This is the happy path. The key separates width=400 from width=800, ignores tracking noise, and keeps public image bytes away from the origin after the first fetch.

Now change one input. Marketing asks for logged-in users to see a personalized banner at:

/products/42/banner

The response depends on a user cookie. If the CDN stores it under only host and path, the first user's banner can become a shared response. The correct design is different: mark the response private or uncacheable at the shared CDN, or create a safe public variant whose key includes only public segmentation such as locale or device class. Personalization should not accidentally hide inside a cache key that looks public.

Origin Shielding and Request Collapsing

Origin shielding protects the origin by concentrating misses through one or a few shield caches. It is most useful when many edge locations can miss the same object around the same time. Without a shield, a global launch can create a miss storm:

edge A miss -> origin
edge B miss -> origin
edge C miss -> origin
edge D miss -> origin

With a shield:

edge A miss -> shield miss -> origin
edge B miss -> shield waits or hits -> no origin request
edge C miss -> shield waits or hits -> no origin request
edge D miss -> shield waits or hits -> no origin request

Some CDNs also support request collapsing, where concurrent misses for the same key are coalesced so only one upstream request is in flight. That matters for expensive objects such as image transformations, large downloads, or API responses that are safe to cache briefly.

Shielding has costs. The shield adds a network hop. If the shield region is poorly chosen, users may see extra latency on misses. If the shield has an incident, it can become a shared dependency for many edges. Shielding is a pressure valve, not a correctness substitute. If the cache key is wrong, shielding can efficiently spread the wrong object.

Operational Failure Modes

Failure: full query string fragments the cache. Tracking parameters, randomized query values, or cache-busting timestamps can create millions of keys for identical content. Hit ratio drops and origin load rises. Normalize the key around representation-changing inputs.

Failure: key is too broad. Ignoring width, locale, encoding, or another representation-changing input can serve the wrong bytes. High hit ratio is not proof of correctness.

Failure: user-specific content enters shared cache. Cookies, authorization headers, account pages, and personalized prices need strict policy. Shared CDN cache should store public representations unless partitioning is explicit and tested.

Failure: origin shield hides an origin capacity problem until a purge or deploy. A warm shield can make origin load look low. After cache expiry, purge, or a new product launch, the origin may suddenly receive many misses. Capacity tests should include cold-cache and shield-miss scenarios.

Failure: edge routing changes the incident shape. One region can have a cache or routing problem while others are healthy. Global averages hide this. Break down CDN metrics by edge region, cache status, host, route, and origin.

Useful signals include cache hit ratio by route, origin request rate, cache status (HIT, MISS, BYPASS, STALE), normalized cache key dimensions, top miss keys, response Age, TTL remaining, shield hit ratio, origin latency, 5xx rate by edge, object size, and whether a request included cookies or authorization.

Design Review

Close the lesson and inspect one URL from a service you know. Answer:

What public representation does this URL identify?
Which query parameters change the bytes?
Which query parameters are only tracking or noise?
Which request headers can change the response?
Can a cookie or Authorization header appear?
Should the CDN store it, bypass it, or cache only a public variant?
What happens on a cold cache in five regions at once?
What metric proves the origin is actually shielded?

This review should produce a cache-key policy, not just a yes/no answer about caching. A mature policy says what varies, what is normalized, what is never shared, and how operators can tell whether the CDN is protecting the origin without corrupting representation identity.

Connections

The DNS lesson showed how users find a starting edge. This lesson starts after that resolution step: once the request reaches a CDN edge, cache keys and edge policy decide whether the origin is needed.

The next lesson goes deeper on purge, surrogate keys, and invalidation. This lesson focuses on what gets cached and why; the next one asks how to update or remove cached content when the underlying product, price, or page changes.

Resources

• [RFC] HTTP Caching RFC 9111
  • Focus: Use it for shared cache behavior, freshness, validation, Vary, and the HTTP model beneath CDN policy.
• [RFC] HTTP Semantics RFC 9110
  • Focus: Use it for representation metadata, selected representation, request headers, and response semantics.
• [DOC] Cloudflare: Cache Keys
  • Focus: Use it for a concrete view of custom cache keys and how query strings, headers, and cookies can affect CDN identity.
• [DOC] Fastly: Shielding
  • Focus: Use it to understand origin shielding as a second-level cache that reduces duplicate origin fetches.
• [DOC] MDN: Cache-Control
  • Focus: Use it for practical examples of public, private, max-age, s-maxage, and stale response directives.

Key Takeaways

• A CDN improves delivery only when the cache key matches the real public representation identity.
• Broad keys can serve the wrong object; narrow keys can fragment the cache and push avoidable work to origin.
• Origin shielding and request collapsing reduce duplicate origin fetches, but they do not fix unsafe cache policy.
• Debug CDN behavior by looking at cache status, key dimensions, edge region, shield hit ratio, origin load, and whether user-specific signals were allowed into shared cache.