How a CDN brings a file closer to a readerFollow the request, the cache key and the copy

Identify the origin and the edge

The origin is where a resource comes from in this example: a server holding /images/brake-diagram-v1.svg. An edge location is a place in the delivery network that can handle a reader’s request. The request can reach an edge through the provider’s routing and network design. “Nearby” means useful network proximity, not a promise that the chosen machine is the geographically closest one.

The edge is not a magic duplicate of the whole website. It may proxy a request, serve cached content, apply other configured logic or contact the origin. Whether a particular response is reusable depends on the provider, resource and configuration. A CDN hostname alone does not establish that a page is cached.

Follow an eligible first request

Assume the public diagram is explicitly eligible for shared caching, its cache key includes the intended URL and the cached response is initially absent. The edge requests the diagram from the origin, receives a response and can store a copy under the configured policy. The reader receives the response. That miss still depended on the origin; a CDN cannot serve an absent file merely because the network exists.

Now a second reader requests the same key while the stored response is fresh. Our simplified edge returns the copy without another origin body fetch. The teaching fixture records one miss and one hit. It demonstrates a possible reuse decision, not real network latency, billing or a benchmark for a vendor.

A key decides which requests share a copy

Suppose the diagram has English and Hindi variants. If the application varies the body by language but the cache key ignores that distinction, a reader may receive the wrong version. The same problem is more serious for personalized account content. A cache needs a deliberate rule about which requests may share a response; it does not understand your business rules automatically.

Do not casually enable shared caching for logged-in pages, authorization-dependent APIs or responses containing private data. Review the provider’s behavior for cookies, authorization, cache-control fields and custom rules. Cloudflare’s ordinary defaults do not cache every HTML or JSON response. Worker logic and explicit rules can change behavior, so inspect the actual deployed configuration rather than repeating that default as a universal guarantee.

Freshness and file names solve different problems

A freshness lifetime says when a stored response can be reused under the policy. Updating a file at the origin does not necessarily replace every fresh cached copy immediately. If the diagram changes, a versioned name such as brake-diagram-v2.svg creates a distinct address. Existing pages must also update their links; a new file name does not repair an old reference on its own.

Invalidation and revalidation are other mechanisms. Revalidation can ask whether a stored response remains usable; some policies allow serving stale content during background validation. This lesson’s fixture uses a simpler rule: at expiry, fetch a new copy. That chosen simplification must not be mistaken for every CDN’s response to expiration or an origin failure.

Trace the small example

The clock starts at zero, the lifetime is 60 seconds and the origin holds version v1. At time zero the result is MISS(v1). At time 20 it is HIT(v1). At time 60 our model fetches again. Change the origin to v2 before that last request: the result becomes MISS(v2). A separate /account request marked non-shareable bypasses this model’s store every time.

Diagnose before purging everything

For an unexpected old image, compare the exact requested URL, cache-relevant response fields, provider cache status and returned bytes. A browser cache, service worker and edge cache are different layers. An apparently successful purge at one layer does not establish that every reader now sees the same content. Keep the original evidence and change one rule at a time.

Limits and a useful decision

Use shared caching for responses that are truly safe to share and whose update behavior you understand. Our in-memory simulation has one edge, no real geography, no eviction pressure and no network failure. It explains eligibility, keys and freshness; it does not test Cloudflare settings or guarantee performance. The separate HTTP caching lesson covers response reuse semantics in more detail.

References

Sources used to check the explanations and examples are listed below.

1. Cloudflare: default cache behavior
2. Cloudflare: revalidation

Found a mistake? Send a correction with this lesson’s title, URL and disputed detail. No login needed.