CDNs and the Edge
CDNs and the edge are distributed proxy layers that terminate user traffic near the user, route it with anycast, and serve cached responses when a request matches a configured cache key. They reduce latency and origin load for cacheable work, but they do not magically accelerate uncached, personalised, or poorly keyed dynamic requests.
The problem is distance and concentration. Without a CDN, users everywhere connect back to the same origin region, so round trips are longer, bandwidth is paid from the origin side, and traffic spikes land on the application servers. Static assets are the obvious win, but API responses, rendered pages, redirects, and image variants can also benefit if they are safe to reuse.
Anycast is how the same public IP can lead to different places. Many CDN points of presence advertise the same prefix through BGP, and the user’s network picks a route according to routing policy. Once the request reaches an edge, the CDN builds a cache key from things such as scheme, host, path, query string, and selected headers. A match returns the stored response; a miss goes to origin and may be stored.
The main trade-off is correctness versus reuse. If the key ignores something that changes the response, such as encoding, region, language, or authentication state, users can receive the wrong content. If the key includes too much, such as every cookie, most requests become unique and the cache is nearly useless. Purging also follows the key, so changing a query string can create a different object.
Engineers meet this in headers, CDN rules, and edge code. `Cache-Control` decides whether and how long a response can be reused; `Vary` splits stored variants by request header; provider settings choose which cookies, headers, and query parameters participate in the key. Edge functions can normalise URLs, redirect, run bot checks, or rewrite requests before lookup, but they still cannot cache data that must be freshly computed per user.
Common questions
- Does anycast always send users to the nearest edge location?
- No. Anycast sends users according to BGP routing decisions, not a map lookup. The selected site is often nearby, but routing policy, ISP preferences, congestion workarounds, and failures can send traffic somewhere else. Treat anycast as a scalable routing mechanism, not a guarantee of geographic optimality.
- What exactly is a cache key?
- A cache key is the identity the CDN uses to decide whether a stored response matches a request. It commonly includes scheme, host, path, query string, and chosen headers, and may include cookies. Two requests that differ in any keyed component are different cache entries, even if the origin would return the same bytes.
- What can the edge not do for performance?
- The edge cannot make every origin-bound request fast just by being present. If responses are marked `no-store`, depend on per-user cookies, or require fresh database work, the CDN must forward them. It can reduce connection distance, terminate TLS, and run lightweight logic, but origin latency still dominates uncached work.
- Is it safe to cache HTML at the CDN?
- It depends on what makes the HTML vary. Public, identical pages can cache well. Personalised pages need careful headers and keys, often `private` or variation by authentication-related inputs. The common misunderstanding is that HTML is either always unsafe or always fine; the real question is whether two users may receive the same response.