How CDNs Work

0. Where TaskFlow Is Right Now

In the last lesson TaskFlow got a working Redis caching layer — /api/tasks now mostly doesn't reach the DB at all. But notice that everything we have done so far is inside the origin — the request came all the way to your server, and then we stopped it from going to the DB.

Now a completely different question: what if the request never had to reach your server at all?

TaskFlow's users are in Dhaka, Singapore, London — everywhere. Your origin server is in one place. If every request from a user in London has to cross half the planet, then no matter how fast Redis is, you can't beat the speed of light — a round trip between Dhaka and London alone is ~200 ms.

In Lesson 4.1 we saw the CDN at a glance in the hierarchy. Today we go inside.

1. Theory

1.1 How the request reaches the nearest edge at all

First, a puzzle: you type taskflow.app, and someone in Dhaka reaches the Dhaka edge, someone in London the London edge — yet there is only one domain name. How?

The answer is Anycast — the same IP address is announced from hundreds of places around the world at the same time. Internet routing (BGP) then sends each request towards the instance of that IP that is closest in network terms.

        user in Dhaka   ──> 104.21.x.x ──> Dhaka PoP
       user in London   ──> 104.21.x.x ──> London PoP     ← same IP, different destination
     user in Sydney     ──> 104.21.x.x ──> Sydney PoP

In Lesson 2.1 you saw DNS-based routing (giving different users different IPs). Anycast is better than that, because there is no problem of old answers getting stuck in DNS caches — the network itself makes the routing decision for every packet.

1.2 Cache Key — what the edge uses to call something "the same thing"

When a request reaches the edge, it thinks: "do I already have this thing?" — but what "this thing" means is decided by the cache key.

By default it is roughly:

cache key = scheme + host + path + query string
            https   taskflow.app  /logo.svg   (no query)

Here is the first trap. The query string is part of the cache key — so to the edge these two are completely different things:

/logo.svg                      ← one entry
/logo.svg?utm_source=facebook  ← another entry, fetched separately

If links come in from a marketing campaign with 10 different utm_* parameters, 10 separate copies of the same logo pile up on the edge, and the first hit for each goes all the way to the origin. That is why CDNs usually get a rule — "ignore the query string for static assets".

The second trap, and this one is more dangerous — the Vary header. Vary says "which request headers this response depends on":

Vary: Accept-Encoding        ← reasonable (separate copies for gzip and brotli)
Vary: Accept-Language        ← reasonable (separate by language)
Vary: Cookie                 ← effectively turns the cache off

Why is the last one a disaster? Because every user's cookie is different, meaning a separate cache entry per user — the hit ratio drops to almost zero, while you think the CDN is working.

1.3 Cache-Control — who is instructing whom

This header causes the most confusion, because the same header has two different audiences — the browser and the CDN.

no-cache does not mean "don't cache" — almost everyone gets this wrong. It means "cache it, but ask before every use". If you want "don't keep it at all", that is no-store.

This combination is the most useful one in TaskFlow:

Cache-Control: public, max-age=60, s-maxage=600, stale-while-revalidate=300

That is — 1 minute for the browser, 10 minutes for the CDN, and even after the CDN's 10 minutes are up, for the next 5 minutes it will serve the stale copy immediately and quietly fetch a new one in the background.

Note stale-while-revalidate — this is the technique that stops everyone rushing to the origin together the moment a TTL ends. In the next lesson (4.6) we'll see this problem is called a cache stampede, and the same technique can be applied in Redis too.

1.4 Conditional requests — no need to refetch the whole thing on expiry

A TTL ending doesn't mean the whole file has to be downloaded again. The edge asks the origin "has this changed?":

Edge ──> origin:  GET /logo.svg
                  If-None-Match: "abc123"
                          │
origin ──> Edge:  304 Not Modified      ← no body, headers only
                  (or 200 + new body, if it really changed)

An ETag is a fingerprint of the content. If it hasn't changed, the origin sends only a 304 — without a body. That means almost zero bandwidth, just one round trip. For a 5 MB image this is a huge saving.

1.5 Purge — how the news reaches 300+ PoPs

Remember question 2 of Lesson 4.1? The user changed their picture, but the old one is still sitting on the CDN for a few more hours. The fix — purge, i.e. telling the CDN "forget this thing right now".

Three kinds:

1. URL purge      →  delete just /logo.svg                 (precise, fast)
2. Tag/prefix     →  delete everything tagged "user-7"     (many at once)
3. Purge all      →  delete everything                     (last resort — dangerous)

Why is "purge all" dangerous? Because in one moment every edge in the world is emptied, and every request after that lands on your origin. An origin that handles 5% of traffic on a normal day is suddenly getting 100%. This is the same danger we saw in question 3 of Lesson 4.2, just at CDN scale — and this is called a cache avalanche.

The news spreads through the CDN's own internal network — you make one API call, and the CDN broadcasts it to all its PoPs. With big providers it takes a few seconds, but it is not instant — so assuming "everyone will see the new one right now" because you purged is wrong.

A technique that removes the need for purges entirely — content hashing. Put the hash of the content in the file's name:

/app.js          ← needs a purge when it changes
/app.a1b2c3.js   ← a new name when it changes, so a purge never comes up

A new build means a new name, which means a new cache key. The old one dies by itself when its TTL ends. That is why it is safe to give these files max-age=31536000 (one year). Your SvelteKit build does exactly this — files in the _app/immutable/ folder have a hash in their names.

1.6 Origin Shield — another layer between the edge and the origin

Having 300 PoPs means the first hit for a thing could go to the origin 300 times — each PoP misses separately.

Origin Shield solves this by adding an intermediate layer:

[300 PoPs] ──> [1 Shield PoP] ──> [your origin]
                                   ← the origin takes the hit only once

All edge misses go to the shield first; the shield fetches from the origin once and serves everyone else. This is also called tiered caching.

Trade-off Table — What Goes Where in TaskFlow

The no-store on the last two isn't optional courtesy. If someone's personal task list is ever cached on the edge by mistake, it can be served to another user. That isn't a performance bug, it is a data breach.

2. Interview Angle

CDN questions almost always come in disguise — "Your users are all over the world, how would you reduce latency?" Don't stop at "I'll use a CDN". Say what goes on the CDN (static assets, public pages) and what never does (personalized API responses), and why — saying the second part shows you know the risk.

The sharpest follow-up: "Something is cached on the CDN and you want to change it right now — what do you do?" — talk about purges, but also talk about content hashing, and say why hashing is better (no purge needed, no reliance on propagation delay). And mentioning that "purge all" can bring an avalanche onto the origin puts you clearly ahead.

Another one that trips many people up: "What is the difference between no-cache and no-store?" — no-cache means "keep it, but check before using"; no-store means "don't keep it anywhere". The two names are confusing, and interviewers know that most people mix them up.

3. Key Takeaway

• Anycast — the same IP is announced worldwide, and routing itself sends the request to the nearest PoP
• Cache key = scheme + host + path + query string; the query string makes separate entries (watch out for utm_*)
• Vary: Cookie effectively turns off CDN caching — a separate entry per user
• max-age is for both browser and CDN, s-maxage only for the CDN, private means the CDN won't keep it
• no-cache ≠ "don't cache" — it means "check first"; "don't keep it" is no-store
• stale-while-revalidate — serve the stale copy immediately even after expiry and fetch the new one in the background (the cure for stampedes)
• ETag + 304 — on expiry you don't refetch the whole body, you just revalidate
• Content hashing is better than purging — a new name means a new cache key, no purge needed
• "Purge all" empties every edge in the world and can bring an avalanche onto the origin
• Personalized/sensitive responses never go on the CDN — this isn't a performance bug, it is a data breach

4. New Terms (Glossary)

5. Reflection Questions

Think about your answer first, then open the Answer Key.

1. TaskFlow's marketing page has Cache-Control: public, max-age=3600. A developer noticed that after updating the page, some users still see the old one after 1 hour, and some even after 2 hours. Even after a CDN purge, the problem remained for a few people. Why?

2. To improve performance, a developer put Cache-Control: public, max-age=300 on TaskFlow's /api/tasks. Everything worked fine on staging (it got faster!), but after going to production, support got complaints — some users can see someone else's tasks. What exactly happened, and why wasn't it caught on staging?

3. TaskFlow's logo is at /logo.svg, with max-age=86400. The design team wants the new logo to show up everywhere right now. Apart from purging, how else could this have been done, and why would it have been better?

6. Practical Exercise

Tier 3 — Design Exercise

TaskFlow is launching a new public sharing feature: any user can make one of their task lists "public", and anyone (without logging in) can view it at taskflow.app/share/{token}. These pages can go viral — a popular list could get thousands of hits a minute.

What you have to decide:

1. Exactly which Cache-Control header would you give /share/{token}? State values for max-age, s-maxage and stale-while-revalidate separately, with reasoning for each.

2. If the user makes their shared list private, what happens to the copy sitting on the edge? What exactly has to happen in your design so that nobody can see it within 1 second? Would content hashing help here — why, or why not?

3. The page shows the user's name and picture. If the user changes their name, how long will the old name stay on the shared page? Is that acceptable? If not, what would you change?

4. A bit harder: a developer proposed — "let's show a small 'you are logged in' banner on the shared page, so users can recognize their own list." How does this one small feature break the whole caching design? How can you keep the feature and avoid the problem?

7. Progress Ledger

=== PROGRESS LEDGER ===
Completed: Module 1, 2, 3 (complete), 4.1, 4.2, 4.3, 4.4
Current: 4.5 — How a CDN works
TaskFlow state: Nginx reverse proxy + LB, horizontal-scale-ready backend,
Redis caching layer (measured: 12ms → 3.7ms), and now the CDN design is decided —
static/public content on the edge (hashed assets with a one-year max-age),
personalized API never (private, no-store)
Terms learned (Module 4 so far): Cache Hierarchy, CDN, PoP, Edge Cache TTL,
Buffer Pool, Cache-Aside, Read-Through, Write-Through, Write-Behind,
Write-Around, Cold Start, TTL, Staleness Window, Cache Invalidation,
Eviction Policy, LRU, LFU, Cache Pollution, Cache Hit Ratio,
Discriminated Union, Fail-safe, Offline Queue, Anycast, Cache Key,
s-maxage, stale-while-revalidate, ETag, Purge, Origin Shield
Weak spots: [where you got stuck — fill this in yourself]
Next: 4.6 — Cache Failure Patterns (stampede, thundering herd, hot key)
=======================

8. Next Lesson

Send the exercise over — especially number 4; that one has caught out countless teams in real life.

When you are ready, write next — Lesson 4.6, the last lesson of Module 4. So far we have seen what happens when the cache works. Now we'll see what happens when the cache breaks — and the strangest part is that the cache's most dangerous failures happen precisely when it was working fine. Stampedes, the thundering herd, hot keys — all three are problems that exist because the cache is there.