What it's for
- The caching chapter kept hot answers beside one server. A CDN is the same move at world scale: edge caches in many regions, so the long trip to the origin happens once per region, not once per user.
- Static, shareable bytes gain the most: images, video, scripts, downloads. Per-user or private responses must not be shared-cached at all — they still travel to the origin every time, as the third sandbox replay shows.
Good to know
Your request doesn't simply go to the geographically nearest edge: the provider steers you with its own routing (DNS or anycast), and "nearby" doesn't guarantee lowest latency — network paths aren't straight lines. Each edge is an independent cache keyed on the URL (plus query strings and selected headers, depending on rules), so region B's first ask misses even after region A is warm; many providers add a shield layer so one region's miss doesn't become a storm of origin fetches, which isn't shown. Freshness is governed by cache-control and TTLs, and a purge or invalidation is not instantaneous worldwide — this toy's policy is a TTL plus a purge that arrives after a delay. A CDN caches responses at the edge; it is not database replication and not a copy of your application. Misses still pay the full trip plus the fill, TLS setup, payload size and connection reuse change real numbers, and a CDN does not make every site universally faster, safer or cheaper.
How it works, step by step
Why the steps go in this order
- The distance is the problem, so the long trip comes first — one client, one origin, one slow answer.
- Repetition across regions is the opportunity: the same bytes, asked from everywhere, each paying the full distance.
- Edges arrive only then, so their job is obvious: the answer, kept near the clients.
- A miss before hits, because every edge starts empty and its first ask still pays the long trip.
- The second region's cold start comes before freshness: independent caches are half the design; knowing when they're wrong is the other half.
Before you rely on it
This is a toy: one origin, two regions, one hot public answer, hand-set timings ("~180 ms" far, "~15 ms" near are illustrative, not measurements, and shorter distance is not guaranteed lower latency). "9 of 10 at the edges" is this toy's hit rate over its declared requests — real rates depend on content eligibility, TTLs, traffic shape and cache size. The tray's geography is a teaching layout, not a map of anyone's network; the cited providers run hundreds of locations with their own routing and measured numbers.