CDNs and Edge Caching

A CDN is a global fleet of caching reverse proxies. Each one — at a point of presence near a population of users — holds copies of your content and serves them without ever touching your origin server. The win is three-fold: latency drops because the content is physically closer (a cache hit in the same city beats a round-trip across an ocean), origin load drops because cache hits never reach you, and traffic spikes and DDoS floods get absorbed at the edge instead of melting your servers.

The caching part is easy. The hard part — the part that causes every CDN incident — is invalidation: knowing what's stale and getting every edge node on the planet to agree to drop it. A CDN that serves the wrong content fast is worse than an origin that serves the right content slow. The whole discipline of running a CDN is managing the gap between "I changed this" and "every edge has stopped serving the old copy," and the cleanest answer turns out to be to never need invalidation at all.

Points of Presence and Anycast Routing

A CDN runs hundreds of PoPs, and the routing trick that sends each user to the nearest one is anycast: the same IP address is announced from every PoP simultaneously, and BGP's shortest-path routing delivers each user to the topologically closest announcement. A user in Frankfurt and a user in São Paulo type the same hostname, resolve the same IP, and land on different PoPs — the network itself does the steering, with no DNS trickery required.

Anycast also gives DDoS resilience for free. A flood aimed at the anycast IP spreads across every PoP rather than converging on one location, so the attack is diluted across the CDN's global capacity instead of saturating a single link. The same property that puts users on a nearby edge spreads an attacker across all of them.

Cache Keys and TTLs

An edge decides whether it already has a response by computing a cache key — by default the request's host plus path, sometimes including query string or specific headers. Two requests that compute the same key share a cached copy, which is exactly why the cache key is where the worst bugs live: include too little and you serve one user's personalized page to another; include too much and your hit rate collapses because every minor variation is a separate entry.

How long the edge keeps a copy is governed by TTL, set primarily through the Cache-Control response header from the origin. max-age sets the freshness window; s-maxage overrides it for shared caches like the CDN; no-store forbids caching entirely. There is usually a hierarchy — a browser cache, then a regional edge, then a shielding tier in front of the origin — and the TTL applies at each layer.

# origin response headers that drive edge caching
Cache-Control: public, max-age=300, s-maxage=86400
#   public      -> a shared CDN cache may store it
#   max-age     -> browsers cache 5 minutes
#   s-maxage    -> the CDN caches 24 hours
Cache-Control: private, no-store   # never cache (per-user data)

Invalidation, Purging, and Versioned URLs

There are three ways to make stale content go away. The passive one is TTL expiry: set a short max-age and the edge re-fetches on its own — simple, but you serve stale content for up to the TTL and pay origin traffic on every expiry. The active one is an explicit purge: call the CDN's API to evict a path from every PoP. Purging is immediate but expensive and dangerous at scale — purge everything on every deploy and you get a thundering herd of cache misses all stampeding the origin at once.

The third way sidesteps the problem entirely. With versioned URLs (cache-busting), you never overwrite content — you publish it under a new name. app.a1b2c3.js replaces app.9f8e7d.js, and because the URL changed, the old cache entry is simply never requested again. You give the versioned asset a one-year immutable TTL and never purge it, because a new deploy means a new filename, not a new copy of the old one. This is why build pipelines fingerprint their assets — it converts invalidation from an operation into a non-event.

Dynamic Acceleration

Not everything is cacheable — a logged-in dashboard, a checkout, a personalized feed all vary per user. CDNs still accelerate these through means other than caching the response. Connection reuse keeps warm, pre-established TLS connections from the PoP back to the origin, so a user's request skips the handshake latency to a distant server and rides an already-open pipe. The user pays the short hop to the nearby PoP; the long hop to origin is already warm.

Edge compute pushes the logic itself outward — running small functions at the PoP to assemble responses, do auth checks, or personalize a cached shell near the user. The pattern is to cache the parts that are common (the page template, the static assets) and compute only the per-user fragment, rather than treating a page as all-or-nothing cacheable. Even uncacheable traffic benefits from terminating TLS at a nearby edge and crossing the slow long-haul leg over an optimized backbone.