Distribute static and dynamic content from edge locations close to users.
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.
| Without CDN | With CDN |
|---|---|
| Every byte from your origin | Repeat visits hit edge |
| Latency = distance to origin | Latency = distance to nearest PoP |
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.
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.
If the PoP does not have the object, it pulls from origin (cache fill), then serves and retains per policy.
Later requests never cross oceans — cost and latency both improve.
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, immutableShort 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.”
| Gain | Mind |
|---|---|
| Lower latency, less origin egress | Purge / invalidation discipline |
| Resilience to spikes | Mis-Cache-Control → stale UX |
| Global anycast edges | Debugging “works for me” vs Sydney user |
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.
Every user pulls static assets from your origin in one region — RTT and bandwidth hurt far-away clients.