Racks in hundreds of cities
A CDN runs racks of cache servers in hundreds of cities, each one peered closely with the local internet providers.
Ask how they all answer to one hostname, because the trick is in the steering. When somebody resolves your CDN address, the provider hands back an edge near them. It does that through DNS, or by having every location advertise the same address and letting the internet deliver to the nearest one.
See the result: somebody in Lagos and somebody in Oslo get different servers from the same address.
Watch each edge behave like any pull cache. If it holds a fresh copy of what was asked for, it answers directly and the request never leaves the city. On a miss it fetches from your origin, stores the response by its headers, and serves it.
Read the economics. Your first user in a region pays the full latency, and the next hundred thousand get the local copy.
Add a middle layer if your provider offers one, often called a shield. A miss in 50 locations then collapses into one fetch through that shield instead of 50 requests hammering your origin, which is stampede protection at the infrastructure tier.
Control all of this with the same HTTP headers browsers already obey. One directive lets any cache hold the object for a day, and another sets a separate, usually longer, lifetime for shared caches while browsers check back sooner.
Two wins beyond latency
Collect two wins beyond latency. Offload, because if the CDN absorbs 95 percent of your requests, your origin is sized for a twentieth of the traffic. That divides a hosting bill by ten or more on an asset-heavy site.
And absorption, because a traffic spike, legitimate or hostile, lands on infrastructure built to soak up terabits a second instead of on your servers.
Worked example
Kofi runs a photography marketplace hosted in Frankfurt, and his analytics show Australian users abandoning at twice the European rate. He measures: a gallery page loads 60 images, and from Sydney each fetch pays a 290 ms round trip to Frankfurt, so even with parallel connections the page takes 8 seconds to settle. He puts CloudFront in front of the image bucket, a one-day s-maxage on image responses, and a versioned URL scheme so he never needs to purge. The first Sydney visitor to any gallery still pulls from Frankfurt, but every subsequent local request is served from the Sydney PoP at about 15 ms. Page settle time drops to 1.4 seconds, Australian bounce rate converges with Europe's within a month, and his origin bandwidth bill falls 88 percent as a side effect.