a content delivery network

Imagine a popular author whose books are printed only in one city. If everyone in the world had to order from that one printing house, shipping would be slow and the printer would be overwhelmed. Instead, the publisher stocks copies in warehouses on every continent, so a reader is served from the nearest warehouse. A content delivery network is exactly that for the web: a globally distributed fleet of servers (called edge or surrogate servers) that cache and serve a website's content from locations physically close to users, instead of everyone reaching the single origin server.

Here is the flow. A site offloads its content (images, scripts, video, often whole pages) to the CDN. When you request something, you are steered to a nearby edge server rather than the distant origin — this redirection is done either by DNS (the site's DNS resolution returns the address of the closest edge cluster for your location) or by IP anycast (many edge servers share one IP address, and the network's own routing delivers you to the nearest one). If that edge already has a copy, it serves a cache hit instantly; if not, it fetches once from the origin (a cache miss and fill), stores the copy, and serves it — and then every later nearby request is a fast hit.

Why it matters: a CDN attacks the two enemies of web speed at once. It slashes latency by shrinking the physical distance and thus the round-trip time, and it shields the origin from load and traffic spikes by absorbing most requests at the edges — so a modest origin can serve a global audience and survive a flash crowd. CDNs also commonly provide TLS termination, compression, and DDoS absorption at the edge. The honest limits: a CDN excels at content that is the same for many users (static assets, video segments); highly personalized or rapidly changing data is harder to cache and may still require the origin, and a CDN adds its own layer to debug, secure, and trust.