CDN

What it means

A content delivery network (CDN) operates distributed edge services between visitors and a website's origin. Its edges can cache eligible responses and deliver them without contacting the origin every time. Depending on the product and configuration, the CDN may also proxy requests, route traffic or apply security policies. It is not synonymous with DNS, and a CDN is not simply a browser cache. HTTP caching CDN behavior

A nearby edge can reduce repeated long-distance transfers for cacheable content, but there is no universal speed guarantee: a miss still needs origin work, and connection and application costs remain.

Try it

Simulation — compare two independent edge caches. Request a public resource at edge A, repeat it, change the origin version or choose edge B. The result shows HIT, MISS or BYPASS together with the specific edge's stored version and lifetime.

The first public request at A fetches origin v1; a repeat before expiry reuses A's saved v1. Change the origin to v2 and repeat at A: a fresh cached v1 can still be eligible. A first request at B can fetch v2 because B has no saved copy. Those different versions are not evidence that the origin edit failed.

Advance to the exact expiry boundary or purge the selected edge's exact /guide key, then request again. A purge of the wrong key stops; a purge at B does not silently remove A. TTL zero prevents reuse in this fixture. The TTL control affects subsequent fills, not a lifetime already saved.

Reset removes both synthetic caches, history and virtual time and restores origin v1. No CDN account or network is accessed. This model deliberately excludes multi-tier caches, revalidation, routing decisions and provider-specific purge propagation. Its private-response bypass is a declared shared-cache safety rule, not a claim that every provider's default configuration is identical. HTTP cache controls One provider's documented defaults

The origin is still part of the system

The origin remains authoritative for content, unless an intentionally designed alternative supplies it. A cache miss, expired object requiring validation, uncached API call or certain errors can still contact origin. Revalidation may use an ETag or last-modified validator rather than downloading a full representation. Revalidation

A purge or invalidation request can remove/revalidate edge copies under the provider's rules, but does not guarantee that every browser cache or another intermediary discards its own copy. Likewise a CDN's cache hit does not prove that the origin currently works. Testing only a cached URL can mask an origin outage.

What to check when content looks old

1. Compare the exact URL, method and relevant request headers. Two cache keys may refer to different responses.
2. Inspect response Cache-Control, Age, ETag and any documented edge cache-status fields. Provider-specific statuses should not be generalized to every CDN.
3. Establish whether the result came from browser cache, CDN edge, proxy or origin. Revalidate or invalidate at the layer that owns the stale copy, with approved production controls.
4. For logged-in pages, confirm that private content is not unintentionally stored in a shared cache. A broad cache-everything rule can defeat an application's assumptions.

In practice

Use a CDN for suitable shared assets and measured geographic delivery needs, not as a substitute for a healthy origin, reliable deploys or correct cache headers. Learn Browser cache to distinguish local reuse, Reverse proxy to understand upstream routing, and Latency vs bandwidth for a deliberately bounded timing model.

Key takeaways

A CDN can route and deliver responses without caching all of them. Trace the exact resource, edge, eligibility and freshness before comparing versions. Origin publication, edge invalidation and browser-cache behavior are separate events; verify the layer that actually served the response.