How Things Work

CDN & Edge Computing

How a global cache network serves content from close to the user — edge PoPs, cache hit/miss, TTLs and Cache-Control, invalidation, and running code at the edge.

How It Works

A Content Delivery Network is a fleet of cache servers spread across the globe. By serving content from an edge near each user instead of a single far-away origin, it slashes latency, absorbs traffic spikes, and shields the origin. The art is in cache headers and invalidation — caching as much as possible for as long as safe, without ever serving stale code.

Push Content to the Edge

A CDN is a global network of cache servers (Points of Presence) close to users. Instead of every request travelling to your single origin, it's served from the nearest edge — cutting latency from hundreds of milliseconds to tens, and offloading the origin.

First Request Misses, Fills the Cache

The first time an edge is asked for an asset it's a MISS: the edge fetches from the origin, stores a copy, and serves it. Every subsequent request in that region is a HIT served locally. Each edge fills independently, driven by real traffic.

TTLs & Cache-Control

Cache-Control / s-maxage headers tell the edge how long to keep content. Static, content-hashed assets are cached for a year (immutable). HTML and API responses use short TTLs or stale-while-revalidate so users get an instant (possibly slightly stale) response while the edge refreshes in the background.

Invalidation & Edge Compute

When content changes you invalidate it — best done with hashed filenames (a new URL per deploy) or an explicit purge call. Modern CDNs also run code at the edge (edge functions/middleware) for redirects, auth checks, A/B tests, and personalization without a trip to the origin.

Key Concepts

📍Point of Presence (PoP)

An edge data center geographically close to users that caches and serves content, reducing round-trip latency.

🗄️Origin

Your authoritative server. The CDN only contacts it on a cache miss or to revalidate, shielding it from most traffic.

🎯Cache Hit Ratio

The fraction of requests served from the edge vs forwarded to origin. Higher = faster and cheaper.

⏰TTL / Cache-Control

Headers that set how long an edge may serve a cached copy before revalidating with the origin.

♻️Stale-While-Revalidate

Serve the cached copy instantly while fetching a fresh one in the background — fast and eventually fresh.

🧹Purge / Invalidation

Forcibly evicting content from the edge after a change. Hashed filenames make this automatic.

Cache-Control headers & purge

tsx

1// Cache-control headers tell the CDN what to cache and for how long.
2
3// Immutable, content-hashed asset — cache forever at the edge
4res.setHeader("Cache-Control", "public, max-age=31536000, immutable");
5// e.g. /static/app.4f9a2b.js  → filename changes on every deploy
6
7// HTML that may change — let the edge serve stale instantly while
8// it revalidates with the origin in the background (SWR):
9res.setHeader("Cache-Control", "public, s-maxage=60, stale-while-revalidate=600");
10
11// Per-user / private content — never cache at a shared edge
12res.setHeader("Cache-Control", "private, no-store");
13
14// Invalidate after a deploy:
15// hashed filenames make this automatic; otherwise call the CDN purge API
16await cdn.purge(["/index.html", "/api/config"]);

💡

Why This Matters

CDNs (Cloudflare, Akamai, Fastly, Vercel Edge) are fundamental to web performance and scale — they make sites fast globally and keep origins alive under load. Edge compute is increasingly where auth, redirects, and personalization run. Understanding caching headers, TTLs, and invalidation is core front-end-infra and system-design knowledge.

Common Pitfalls

⚠Caching with stable filenames + long TTLs — deploys serve stale code until the cache expires.

⚠Accidentally caching personalized or authenticated responses at a shared edge (data leakage). Use private/no-store.

⚠Low hit ratio from over-fragmented URLs (query-string variations, no cache key normalization).

⚠Forgetting the origin still needs protection — a cache miss storm (cold cache after purge) can stampede it.

⚠Treating the CDN as only for images — HTML, APIs, and edge logic benefit too (with the right TTLs).

Real-World Use Cases

1Global Product Launch

Scenario

A startup launches and gets featured worldwide. Users in Asia and Europe complain the site is painfully slow, even though it's fast from the US office where the single origin server lives.

Problem

Every asset — JS bundles, images, CSS — travelled from one US data center to users on other continents, adding 200–400ms per round trip. The origin also buckled under the global request volume.

Solution

They put a CDN in front of all static assets with long, immutable cache headers (hashed filenames) and short SWR TTLs on HTML. Now content is served from edges in each region, latency drops to tens of milliseconds globally, and origin traffic falls by over 90%.

💡

Takeaway: A CDN is the single highest-impact fix for global latency and origin load. Cache aggressively with content-hashed URLs so you get long TTLs without ever serving stale code.

2The Stale Deploy

Scenario

After a deploy, some users keep loading the old JavaScript and hit errors because it expects an API shape that no longer exists.

Problem

HTML referenced /app.js with a long cache TTL but a stable filename. Edges (and browsers) kept serving the old cached file, so users ran old code against the new backend.

Solution

Switch to content-hashed filenames (/app.4f9a2b.js) so each build produces a new URL the CDN has never cached — old and new coexist, and the HTML (short TTL) points at the right one. Where stable URLs are unavoidable, call the CDN purge API on deploy.

💡

Takeaway: CDN caching is only as safe as your invalidation strategy. Hash your asset filenames so a deploy changes the URL — the cleanest invalidation is never reusing a URL.

Join the discussion

Comments

Loading comments...

Cookie preferences

We use essential cookies for sign-in and preferences. With your permission, we also use basic analytics to improve lessons.