CDNs Explained

A Content Delivery Network is a fleet of servers ("edges" or "PoPs") distributed worldwide, each holding cached copies of your content. When a user requests a file, the CDN serves it from whichever edge is closest to them — not from your origin in us-east-1.

Three wins:

1. Speed: a user in Tokyo gets your CSS from a Tokyo PoP in 10ms instead of from Virginia in 200ms.
2. Origin offload: 95% of asset requests never reach your servers. Your bandwidth bill and capacity needs shrink.
3. Resilience: a CDN absorbs traffic spikes (and many DDoS attempts) before they hit your origin.

The trade: cached data can be stale, and you have to think about how to invalidate it.

Two ways content gets to the edge:

• Pull CDN (the default): edges fetch from your origin on first miss, cache, and serve. You change nothing about how you publish files. Cloudflare, AWS CloudFront, Fastly all default to pull. Use this 95% of the time.
• Push CDN: you upload assets to the CDN explicitly. The edge serves them; the origin never gets asked. Used for predictable static content, large video libraries, or strict origin-shield requirements.

For most apps, pull is dramatically simpler and works fine. Push starts making sense when origin egress costs matter and you want to control exactly what lives on the edge.

A request from your browser passes through several caches in a typical CDN setup:

1. Browser cache: the user's machine. Fastest; controlled via Cache-Control headers.
2. Edge PoP: the CDN node serving the user. Most traffic terminates here.
3. Regional cache / shield: a few large mid-tier caches in front of origin. Coalesces requests from many edges so origin sees one request, not many.
4. Origin: your servers.

A cache MISS at one layer is a HIT or MISS at the next. Tuning Cache-Control and the CDN's edge TTL controls how long each layer holds onto things. The further down the hierarchy a request reaches, the slower it is.

Each layer absorbs traffic from the next.

Your origin's Cache-Control header tells everyone downstream how long to cache. Common patterns:

• Cache-Control: public, max-age=31536000, immutable — assets with content-hashed filenames (app.a8b3.js). Cache forever; new versions get new URLs.
• Cache-Control: public, max-age=300, s-maxage=3600 — HTML or APIs with mild freshness. Browser caches 5 min; CDN caches 1 hour (s-maxage overrides for shared caches).
• Cache-Control: private, no-store — user-specific or sensitive responses. Never cached.
• Cache-Control: public, max-age=0, must-revalidate, stale-while-revalidate=86400 — always check freshness, but tolerate stale during revalidation. The pattern modern frameworks use for most pages.

Get these right and the CDN does the rest. Get them wrong and you ship stale builds for hours.

Sometimes you need to forcibly clear something from every edge worldwide. Approaches:

1. Content-hashed URLs: never invalidate at all. New version → new URL (app.a8b3.js → app.de91.js). The most reliable approach; ideal for build artifacts.
2. Versioned URLs (?v=42): similar idea; bump the query string to bust caches. Note: some CDNs ignore query strings by default; check.
3. API-driven purge: most CDNs let you POST a URL to a purge endpoint. Reliable for content you can enumerate (specific pages). Often rate-limited.
4. Surrogate keys / tags: Fastly and others let you tag cached objects with keys, then purge all objects with a key in a single request. Game-changing for content with cross-cutting dependencies.

Rule of thumb: design URLs so you almost never need to invalidate, then use API purges for the rare case.

Modern CDNs let you run code at the edge — Cloudflare Workers, Fastly Compute, Vercel Edge Functions, AWS Lambda@Edge. The pitch: response generation closer to the user, sub-millisecond cold starts, no origin round-trip.

Good fits:

• A/B testing routing
• Auth checks before forwarding to origin
• Image resizing on the fly
• Personalisation of cached HTML

Less good fits: anything that needs a database in another region (you've moved the latency, not eliminated it), heavy compute (edge runtimes are constrained), or strong consistency across PoPs (replication latency is real).

Useful, not magic. The shape of the problem still matters.

CDNs are most powerful for public, cacheable, repeated responses. They help less or not at all for:

• Per-user dynamic responses: each user gets a different page; nothing cacheable at the edge.
• Write-heavy APIs: nothing to cache; the CDN is just a passthrough proxy.
• WebSockets and long-lived connections: CDNs can proxy them but the caching benefit is zero.
• Geographically uniform audiences: if 99% of your users are in one city, the CDN's geographic spread is wasted (though origin shielding can still help).

In these cases the CDN's value drops to "sane TLS termination + DDoS protection" — still nice, but you wouldn't pay enterprise pricing just for that. Match the tool to the workload.