CDNs
- Pradeep P
- 3 days ago
- 4 min read
Layer 1 · Post 8 of 15
Layer 1 — The building blocks · Post 8 of 88
A CDN caches content close to users so the origin server does less work and pages feel faster around the world.
What you'll learn
What a CDN caches, and what it should not cache
Why "close to the user" beats a single origin on another continent
Cache keys, TTLs, and origin shielding in plain language
The idea in one minute
A CDN (Content Delivery Network) is a fleet of reverse proxies in many cities. Users hit a nearby edge node. If that node already has the file, it returns it. If not, it fetches from your origin (your servers or object storage), stores a copy, and then returns it.
User in Bengaluru
|
v
[ CDN edge, nearby ] --cache miss--> [ Origin in Virginia ]
|
cache hit next time
Static assets love this. Personalized HTML is more careful. APIs can use a CDN too, if you know what you are caching.
Why it matters
The speed of light is not a startup problem you can sprint out of. A round trip to another continent is tens to hundreds of milliseconds before your app even runs.
A CDN:
Cuts latency for cacheable bytes (images, JS, CSS, videos, downloadable files).
Cuts origin load. A viral image does not have to leave your S3 bucket a million times.
Absorbs some abuse at the edge (volume, some bots) so origin capacity is for real work.
If your design serves a global audience and you omitted a CDN, interviewers will notice.
How it works
DNS for static.example.com (or the whole site) points at the CDN, often via CNAME.
The CDN uses anycast or geo-DNS so the user lands on a nearby POP (point of presence).
The edge looks up the object by a cache key — typically scheme + host + path + selected query params.
Hit: return the bytes, maybe revalidate with ETag / If-None-Match.
Miss: fetch from origin, store according to Cache-Control / CDN config, return to the user.
What belongs on a CDN
Great fit: versioned assets (app.8f3a2.js), images, fonts, public videos, software downloads, public JSON that changes rarely.
Careful: HTML that includes a username, API responses that differ per cookie, anything with Set-Cookie and "cache everything."
Usually skip or bypass: checkout POSTs, "current stock for this user," anything that must be correct this millisecond unless you designed a short TTL and a safe key.
Cache-Control is the contract
Cache-Control: public, max-age=31536000, immutable — "this URL will never mean something else" (use hashed filenames).
max-age=60 — edges may keep it a minute.
private — browsers may cache; shared CDNs should not treat it as public.
no-store — do not cache.
Wrong headers are how you accidentally cache a logged-in homepage for everyone.
Origin shield
If every edge misses at once (new deploy, expired TTL), they can stampede the origin. Many CDNs pick one regional "shield" that the other edges talk to, so origin sees one miss, not five thousand.
A simple example
Your marketing site's hero image is 2 MB. Without a CDN, every visitor pulls it from Mumbai origin even if they are in Brazil.
With a CDN: the first Brazilian visitor pays origin + fill. The next ten thousand in that region hit the São Paulo edge. Origin graphs stay calm. The Brazil users get a shorter path.
You deploy new JS. Old file was /app.js with max-age=86400. Users keep the old file for a day. You switch to /app.<hash>.js with a long TTL. New HTML references the new hash. Old and new can coexist. That pattern is how modern frontends and CDNs stay friends.
Common mistakes
Caching the whole site with a long TTL because "it's faster." Personalized pages leak. Stale prices make people angry.
Query strings in the cache key accidentally. ?utm_source=twitter creates a unique cache entry per campaign. Either ignore those params or normalize them.
No versioning, purge as a lifestyle. Emergency "purge all" works until it becomes the deploy process. Prefer immutable URLs.
Forgetting HTTPS and cookies. A CDN that forwards all cookies may fragment the cache (every user a unique key) and you pay for a CDN that never hits.
How this shows up in real systems
Cloudflare, Fastly, Akamai, CloudFront, Bunny: the usual networks.
Image/video pipelines: resize at the edge or via a specialized image CDN so origin stores one original.
"CDN in front of the API": used for public, cacheable GETs (product pages, config files) with short TTLs; not a substitute for a correct cache in Redis for per-user data.
Layer 5's multi-region story often starts here: edges everywhere, origin in one or two regions.
Recap
A CDN is many reverse proxies with a cache, placed near users.
Cache immutable, public content aggressively; treat personalized data as radioactive.
Control behavior with cache keys, TTLs, and versioned URLs, not hope.
The CDN is a specialized cache at the edge. Next we talk about caching as an idea, wherever it lives.
Layer 1 · Post 8 of 15
Comments