A viewer in Sydney opens your video streaming app and waits 2s for a page that was already stored on a server in Virginia. The server did not need to compute the page. Network round trips across the ocean caused the wait. A CDN (content delivery network) is a fleet of caching servers spread around the world. It stores copies of your origin's responses and serves them from near the viewer.

This tutorial covers where those copies sit, how requests find them, what identifies them, and how long they may be served. It does not cover how the origin produces the response.

Add one when many viewers far from your origin request the same bytes: images, scripts, video segments, a page that looks the same for everyone in a region. It earns little when your audience sits in the region your origin is already in, or when nearly every response is built for one viewer and cannot be shared. In those cases the edge mostly adds another layer to debug, and an origin close to its users does the same job.

In an interview a CDN is usually one line on the whiteboard, but placement alone leaves the important decisions unanswered: what identifies an object at the edge, what happens to the origin when everything goes cold at once, how to remove a wrong file, and which dynamic responses can still be shared.

At mid-level, placement and the rule that per-viewer responses cannot be shared may be enough. A senior answer usually also needs the cache key, the freshness choice, and an origin-load argument stated in fetch counts rather than adjectives.

Consider a video streaming service whose player bundle, artwork, video segments, regional browse page, and per-viewer continue-watching row cover each delivery category.