7.2 CDN Caching, Origin Pulling, and Traffic Routing

When remote users download the same map, the origin server is already overwhelmed; you need to decide which copies can be placed closer to users on edge nodes.

A CDN is a distributed edge platform, and caching is one of its most common capabilities. It shortens the network path between users and content, reduces load on the origin server, and can handle TLS, request routing, and some security policies at the edge. However, these benefits depend on cacheability, traffic mapping, and origin design, rather than "connecting to a CDN makes things faster automatically alone."

1. The Basic Path of a Single Edge Request

client
  |
  | DNS answer / anycast route
  v
edge point of presence
  |-- fresh cache hit -----------------> response
  |-- stale entry -> revalidate origin -> 304 / new response
  `-- miss ----------------------------> origin or origin shield

A CDN doesn't necessarily have to push all files to global locations first. Many content items are pulled from the origin on the first request that reaches the edge, and only subsequent requests hit the cache; pre-positioning is also viable for large-scale launches or video workflows.

2. The cache key determines which requests share the same response

A typical key includes at least scheme/host/path, and whether query parameters are included in the key depends on the configuration. Vary allows the cache to distinguish stored responses based on specified request fields, such as content encoding or language.

A cache key that's too narrow might serve user A's personalized response to user B; one that's too broad could split each tracking query, cookie, or header variant into separate objects, lowering hit ratio and amplifying storage.

The cache policy should clearly specify:

• Which method/status can be stored;
• Does the shared cache allow storage of authenticated/personalized responses?
• What query, header, or cookie dimensions does the key include;
• How to handle Cache-Control, Expires, ETag, and Last-Modified;
• Can a stale response be used during origin error or revalidation?
• Maximum object size and negative/error caching policy.

3. Freshness, validation, and purge are three separate things

A fresh response can bypass origin checks and be directly reused. For a stale response, use a validator to issue a conditional request; when the origin returns 304, update the cache's metadata and continue serving the stored content.

Purge/invalidation is a CDN vendor control plane capability, not an HTTP caching semantic guarantee of global instant transactions. Purge takes propagation time and may fail to hit the expected object due to key mismatches.

Static assets are typically well-suited for content-addressed or versioned URLs:

/assets/app.4f3a91c2.js

When content changes, a new URL is generated; old URLs can be set with a long freshness lifetime. The HTML entry point uses a shorter freshness or validation period to reference the new asset URL. This is easier to reason about than having to precisely purge old objects globally on every release.

4. Miss Storm and Origin Shield

When a popular object expires, a large number of edges/requests can simultaneously origin-pull, causing a cache stampede. A common mitigation approach:

• request collapsing / single flight: Only one fetch originates from the same key;
• freshness jitter: avoid a large number of objects expiring at the same time;
• stale-while-revalidate / stale-if-error strategy;
• origin shield: multiple edge requests aggregate misses toward a single shield cache;
• origin capacity limit and circuit breaker.

Shield has one more hop; its value comes from miss aggregation and origin protection, not from lower latency on every request.

5. Geo-aware DNS and anycast do not guarantee "geographic proximity"

A CDN can map a recursive resolver's or client's subnet to a specific edge cluster via DNS responses, or enable multiple sites to broadcast the same anycast IP, with the path selected by BGP route selection. In practice, deployments often combine multiple mechanisms.

GeoDNS often sees recursive resolver addresses, not necessarily end-user addresses; EDNS Client Subnet can pass along part of the client prefix, but introduces a trade-off between privacy and cache fragmentation. DNS answers are still cached for the duration of their TTL and cannot make per-request instantaneous load decisions.

Anycast chooses the best path based on routing policy, not the shortest Euclidean distance or the lowest latency site. BGP itself does not consider CDN application queue depth. Operators can influence the mapping through route advertisement or withdrawal, communities, and traffic engineering, but additional health signals and failover design are required.

6. Observe the cache, don't guess the brand from vendor headers

curl -sS -D - -o /dev/null https://www.example.com/assets/app.js

Follow:

• Cache-Control, Expires, ETag, Last-Modified;
• Age is the current age information of the response in the cache system, not evidence of a hit on a specific CDN brand;
• Via, Server-Timing, or vendor-specific cache-status header; their semantics should be checked in the provider's documentation;
• Response is HIT, MISS, BYPASS, or STALE?
• Can the Request ID/trace be correlated with the origin log?

Searching for strings like cf- or x-cache solely in the response header is not a reliable way to determine whether CDN is being used: headers can be deleted, modified, or generated by other proxies.

7. Cache Correctness and Security

CDN is a shared intermediary; a cache policy error can amplify data leakage. Focus your inspection on:

• Is the authenticated/private response stored in the shared cache?
• Does the cache key ignore changes to the response's header/cookie/query?
• Can an untrusted host/header pollute a generated redirect or absolute URL?
• Is Origin accessible only to trusted CDN endpoints, and how is edge-to-origin authentication performed?
• Signed URL/cookie expiration, scope, and key rotation;
• Can compression/range requests and object size limits be abused?

When TLS is terminated at the client-to-edge level, the edge can see the plaintext data in order to perform HTTP caching and routing. Edge-to-origin represents a separate security boundary that requires its own TLS authentication, authorization, and certificate lifecycle management.

8. Acceptance Issues

1. Design separate cache policies for versioned JS assets and HTML entry points.
2. Why can Age alone not prove that the response comes from a specific CDN?
3. Explain the failure modes of cache keys that are too narrow versus too wide.
4. Design request collapse, stale policy, and origin shield for a hot object's expiry.
5. Why does anycast not equal application-aware load balancing?

Next, move on to 7.3 Load Balancing Algorithms, Health Checks, and Retry Boundaries.

Reference

• RFC 9111: HTTP Caching
• RFC 5861: HTTP Cache-Control Extensions for Stale Content
• RFC 7871: Client Subnet in DNS Queries
• RFC 4786: Operation of Anycast Services