You set Cache-Control: max-age=3600 on your responses, put a static asset behind cdn.example.com once, and watched it serve fast. Then someone asked "why is our hit ratio 30%?" and "why are users still seeing the old version 8 minutes after we deployed?" and you realized you had no mental model for what the CDN actually does between the user's browser and your origin.

This curriculum builds that mental model from scratch, in the order a single HTTP request actually flows: browser → DNS → anycast → POP → cache lookup → (origin shield) → origin. Every concept is introduced in the scene where it first becomes load-bearing — TTL only after edge caches exist, revalidation only after staleness is a state, SWR only after the user-visible wait at the TTL boundary is felt, purge only after SWR ships you a bug, and the Vary footgun only after purge invalidates entries that the cache key has already shattered into a thousand variants.

Resist the urge to "describe a CDN." Make decisions yourself, defend them, and let the AI push back. The point is to build the dial-by-dial intuition that lets you debug a real production hit-ratio collapse — not to recite Cloudflare's product page.