CDNs

A CDN places caches in many cities so a user’s packets stop close to home. The first request for an object (a miss) fetches from your origin and stores the response. Later requests in that city are hits. The win is latency and origin load. The risk is serving the wrong bytes to the wrong person, for too long.

What belongs there

Versioned static assets, images, and video segments. Give the object a URL that changes when the bytes change, and a long Cache-Control: public, max-age=.... You then almost never purge. Purges are for takedowns, security mistakes, and the rare mutable URL you could not avoid.

Anonymous identical pages (a marketing page, a public video watch page’s shell) can be cached if the cache key includes everything that changes the body: path, relevant query parameters, and sometimes Accept-Encoding or language. Do not include a random cookie or the key will never hit.

What does not

Personalized JSON, account pages, and anything with a Set-Cookie that is specific to a user. Cache-Control: private keeps it in the browser and out of the shared edge. APIs that authorize per caller should generally bypass the CDN cache or vary on an authorization header you have thought about carefully. Varying on the full bearer token is a per-user cache with extra steps and a leak risk if you get the vary wrong.

Video and large files

Clients request byte ranges. The CDN and the origin must both honor Range. Segmented playlists (HLS or DASH) make each segment an independent cacheable object. That is the usual answer for YouTube-shaped designs, and it is covered on that problem page.

Miss behavior

A hot object that expires everywhere becomes a burst of origin requests. Jitter TTLs, use an origin shield, or serve stale while one request refreshes. The same stampede you can describe for Redis applies at the edge, with more zeros.