Content Delivery Networks: Cache Keys, Freshness and Origin Load

A CDN is a delivery layer with a cache policy

A content delivery network routes requests through distributed infrastructure. A suitable edge can serve a cached response or fetch from an origin. Routing depends on network conditions, provider policy, and available capacity; the selected server is not necessarily the geographically closest one.

Caching can reduce origin traffic and shorten the network path for reusable responses. A cache miss, an uncacheable response, or a poorly chosen cache key can still require the full origin trip. Edge compute, TLS termination, and traffic filtering are related capabilities, not proof that every response is safe to share.

Calculate what is actually offloaded

Assume one million daily requests for a 1 MB public image, using decimal units. Delivery is 1 TB/day. At a 95% byte hit ratio, origin transfers about 50 GB and the delivery layer serves the remainder from cache, excluding revalidation and overhead.

That is an origin bandwidth reduction, not automatically a 95% bill reduction. A cost comparison includes delivery bandwidth, request charges, origin fetch charges, invalidation, compute, and any contractual minimums. Use the selected provider's current pricing when estimating an actual bill.

For a mixed workload, request hit ratio can mislead. Ninety-nine tiny cached icons and one large uncached download produce a 99% request hit ratio while most bytes may still come from origin. Measure byte and request ratios separately.

The cache key defines who shares a response

A key often includes the URL and some configured request attributes. If language changes the response, the cache must distinguish the relevant language variants. If an authenticated customer's private page is cached under a public URL without the right isolation, another customer can receive it.

Do not fix this by blindly including every cookie and query parameter: that can create a unique cache entry for each request and eliminate reuse. Instead, decide which routes are public, which representations vary, and which must bypass shared caching. Treat authorization before cache lookup as a deliberate design requirement where protected cached content is used.

HTTP defines directives for storage, freshness, validation, and shared caches. In particular, no-cache allows storage but requires validation before reuse, whereas no-store instructs caches not to store the response. HTTP Caching, RFC 9111.

Three policies for three kinds of response

These are starting points for the stated examples, not blanket settings for an entire application. Verify that the provider honors them and that framework or edge rules do not override them. A public article containing a personalized widget requires separate handling of that widget or a different response strategy.

The immutable extension tells supporting clients that a fresh response need not be revalidated. It does not make a mutable filename safe to cache for a year. HTTP Immutable Responses, RFC 8246.

Correcting a cached page

Suppose a price page is cached for five minutes. At 12:00, the price changes at origin; an edge that fetched at 11:59 may retain the old response until 12:04. A purge can reduce that interval, but its delivery and scope need verification. A browser holding a separately fresh response may not ask the edge again immediately.

For immutable assets, use a new versioned URL and update the referring HTML. For mutable pages, choose a freshness bound that matches the consequence of staleness. Checkout must validate the current payable amount regardless of what a cached catalog page displayed.

Validators such as ETag can let a cache confirm that a response remains current without transferring the entire body. Validation still reaches an upstream system; it does not mean zero origin work.

Cold caches can overload the origin

A purge of every object can synchronize misses. Assume origin normally receives 100 requests per second behind a 99% hit ratio, while total demand is 10,000. Losing the cache can expose origin to most of that total demand before entries refill.

Request collapsing, an origin shield, bounded fetch concurrency, and deliberate prewarming can reduce the surge. Serving stale responses during an error can improve availability only for content where stale data is acceptable. Never treat a stale authorization decision as equivalent to a stale public image.

Protect the origin-to-edge connection as well as the browser-to-edge connection. Configure authenticated TLS as appropriate and restrict direct origin access if the architecture relies on edge enforcement. A CDN's filtering does not protect a publicly reachable alternate origin address automatically.

Verify the behavior from two users and a cold edge

Request a public asset repeatedly and inspect its age, headers, and provider cache-status information. Then test two authenticated users to confirm private data never crosses accounts. Change a mutable response, issue a targeted purge, and measure when different clients receive the correction. Finally, simulate a cold cache with bounded traffic and watch origin latency and concurrency.

These checks reveal correctness, freshness, and capacity. A global point-of-presence count or an invented latency percentage cannot replace them. For large video objects, continue with the worked streaming capacity example.