CDNs & Edge Networks

How CDNs Work

A Content Delivery Network is a geographically distributed network of cache servers (called Points of Presence, or PoPs) positioned close to end users. When a user requests a resource, the CDN routes the request to the nearest PoP rather than the origin server. If the PoP has a cached copy (a cache hit), it responds immediately. If not (a cache miss), it fetches from the origin, caches the response, and serves it.

The latency reduction is significant. An API origin in us-east-1 has a round-trip time of ~200ms to a user in Sydney. A CDN edge node in Singapore reduces that to ~15ms. For static assets, images, JavaScript bundles, CSS, fonts, the entire request is served from the edge and the origin is never touched. For dynamic content, CDNs can still help by terminating TLS at the edge (saving one full round trip for the TLS handshake) and compressing the response.

Anycast routing

Most CDNs use anycast IP routing: many edge servers share the same IP address, and the internet's routing protocol (BGP) directs each client to the topologically nearest one automatically. No DNS lookup is needed to find the nearest edge. The routing is transparent to the client, it sends a request to the CDN's IP and receives a response from whatever PoP is closest.

Unicast CDNs (like AWS CloudFront) use DNS-based routing instead: a DNS query for assets.example.com returns the IP of the nearest edge location. This requires a DNS lookup on each new connection but achieves similar geographic routing.

Pull vs push CDN

Major providers

Cache-Control: Directing CDN Behavior

Cache-Control is the HTTP response header that tells browsers and CDNs how to cache a response. It is a comma-separated list of directives, each controlling a specific aspect of caching behavior. Getting these directives right is the primary lever for CDN cache hit rate and performance.

The most important distinction: some directives apply only to shared caches (CDNs) via the s- prefix, while others apply to all caches including the browser. This lets you cache aggressively at the CDN while controlling what the browser holds locally.

Key directives

Cache-Control: max-age=3600

Cache-Control: max-age=3600, s-maxage=86400

Cache-Control: no-cache

Cache-Control: no-store, private

Cache-Control: private, max-age=0

Cache-Control: public, max-age=600

Cache-Control: max-age=300, stale-while-revalidate=60

Cache-Control: max-age=31536000, immutable

Caching strategies by asset type

Cache-Control: public, max-age=31536000, immutable

Cache-Control: public, max-age=0, s-maxage=300, stale-while-revalidate=60

Cache-Control: public, s-maxage=60, stale-while-revalidate=30

Cache-Control: private, no-store

Cache-Control: public, max-age=31536000, immutable

Cache invalidation

Phil Karlton famously said there are only two hard things in computer science: cache invalidation and naming things. The CDN layer makes invalidation concrete. When you deploy new code, CDN edges may still serve the old cached version for hours.

What to Put on a CDN

Not everything belongs on a CDN. The rule is: if the response is the same for every user who requests it, and it is safe to store at a shared cache, it belongs on a CDN. If it is personalized, authenticated, or written by the request, it does not. Misconfiguring cache headers on authenticated content is a security vulnerability, not a performance problem.

Security headers via CDN

CDNs are the right place to inject security response headers globally. A single transform rule (Cloudflare Transform Rules, CloudFront Response Headers Policy) adds headers to every response from every origin without any application code change. This ensures headers are applied even on error pages, redirects, and third-party origin responses.

The Vary header

# Response varies by Accept-Encoding (gzip vs br vs none)
Vary: Accept-Encoding

# Response varies by language, CDN caches one version per Accept-Language
Vary: Accept-Language

# DANGER: Vary: Cookie creates a separate cache entry per cookie value
# Effectively disables CDN caching for that resource
# Avoid on public resources
Vary: Cookie

Edge Computing: Logic at the PoP

A CDN PoP was historically a passive cache: it either served a cached response or fetched from the origin. Modern CDNs now allow deploying executable code at every PoP. Cloudflare Workers, AWS Lambda@Edge, and Fastly Compute@Edge run JavaScript or WebAssembly inside the CDN's edge infrastructure, milliseconds from the user.

The model is fundamentally different from serverless functions running in a single region. Edge workers run in V8 isolates (not containers), which start in under a millisecond. They execute at the PoP nearest to the user, so a user in Tokyo runs their request through Tokyo infrastructure rather than waiting for us-east-1. The trade-off is a constrained execution environment: no Node.js APIs, limited CPU time, and no persistent state without external bindings.

What to do at the edge

Edge runtime constraints

export default {
  async fetch(request: Request, env: Env) {
    const url = new URL(request.url);

    // Public routes bypass auth check
    if (url.pathname.startsWith("/public/")) {
      return fetch(request);
    }

    const auth = request.headers.get("Authorization");
    if (!auth?.startsWith("Bearer ")) {
      return new Response("Unauthorized", { status: 401 });
    }

    const token = auth.slice(7);
    const valid = await verifyJWT(token, env.JWT_PUBLIC_KEY);
    if (!valid) {
      return new Response("Forbidden", { status: 403 });
    }

    // Forward to origin with verified identity header
    const proxied = new Request(request);
    proxied.headers.set("X-User-Id", valid.sub);
    return fetch(proxied);
  }
}