CDN

If you are new here: A CDN (Content Delivery Network) caches HTTP responses at edge PoPs near users. Static assets (JS, CSS, images) are the classic win; with tuning, you can also cache or accelerate some API responses.

The Problem

Your SPA ships a 3 MB JavaScript bundle. A user in Sydney loads the app; every chunk crosses the Pacific to your single origin in Virginia. TTFB and throughput are fine on your office Wi‑Fi — terrible on mobile halfway around the world. Worse, every repeat visit still hammers your nginx for bytes that did not change between releases.

You are not out of CPU yet; you are paying the speed of light and congestion tax on cacheable bytes.

In plain terms: a CDN moves copies of your responses closer to users so latency drops and origin stops being the bottleneck for static and safely cacheable dynamic responses.

That is why CDN belongs in the caching track: it is HTTP caching at planetary scale — same Cache-Control ideas, different geography.

Edge cache

A CDN (CloudFront, Fastly, Cloudflare) keeps copies in PoPs (points of presence — edge data centers distributed worldwide) close to users — the first hop is short.

Analogy: Instead of every customer flying to one warehouse, you stock regional shops.

What changes for users: the request terminates near them. A user in Sydney can fetch app.abcd123.js from an Australian edge instead of your Virginia origin. The browser still sees the same URL shape, but the physical path is shorter.

What changes for your origin: repeat traffic disappears. The origin handles cache fills, purges, and dynamic requests instead of serving the same immutable bytes all day.

Edge miss → origin

If the PoP does not have the object, it pulls from origin (cache fill), then serves and retains per policy.

The first user after a deploy or purge may pay origin latency. Everyone after them gets the warm edge copy. This is why global performance tests should distinguish cold edge misses from warm edge hits.

Operational smell: if every request is an edge miss, the CDN is acting like an expensive proxy. Check Cache-Control, cookies, query strings, authorization headers, and whether the response is marked private.

Edge hit

Later requests never cross oceans — cost and latency both improve.

An edge hit is the happy path: the CDN returns bytes directly, often without touching your origin at all. For static assets, hit ratios above 90% are common when filenames are hashed and cache headers are long-lived.

Tiny example: A 3 MB JS bundle requested 1 million times is 3 TB of origin egress if uncached. With a 98% edge hit rate, the origin serves only the 2% cold or revalidated requests.

Cache-Control

Origins send Cache-Control, ETag, Vary — CDNs respect semantics; immutable assets can cache long, HTML short.

Example for hashed static assets:

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

For HTML, be more conservative. HTML often points to the latest asset names and may include user or experiment state. Static bundles can cache for a year because the filename changes on deploy; HTML usually needs short TTLs, revalidation, or purge discipline.

In plain terms: immutable filenames let you cache aggressively without serving old code forever.

Dynamic and APIs

Short TTL, stale-while-revalidate (SWR — serve the cached copy immediately while fetching a fresh one in the background), and edge compute extend CDNs beyond static files — still HTTP-caching rules.

Gotcha: Personalized JSON (Set-Cookie, Authorization) is usually not safely cacheable at the edge unless you design split paths — default is “dynamic = origin.”

Dynamic caching works best when you separate public and private data. A product-list API can be public for 30 seconds. A user’s cart should usually stay private. Mixing both in one response prevents safe caching.

Debug tip: inspect response headers from the user’s region: Age, Cache-Control, Vary, X-Cache, and Set-Cookie. CDN problems often hide in headers, not code.

Trade-offs

Why this matters for you

Put hashed static assets on a CDN with long max-age; pair with cache busting via filename. Plan purge APIs when you must invalidate HTML or API responses urgently.

Runbook: When legal demands “take that PDF down now,” your lever is often CDN purge + object version, not redeploying the app.

Next: Vertical Scaling — once your CDN handles static load, the origin itself needs to scale.