Caching

Caching is one of the simplest ways to improve delivery. A cache saves a copy of a response so it can be served without a round trip to the origin. The core control surface is the Cache-Control header and the time-to-live (TTL). Freshness and validation determine when a cache can reuse a stored response and when it must contact the origin. Freshness vs validation A cache serves a response when it is fresh. Freshness comes from an explicit lifetime such as max-age or from an older Expires date. After freshness ends, a cache either revalidates or fetches again. ...

Synopsis Caches remain consistent across providers only when cache keys, HTTP caching headers, immutable assets, purge methods, and deployment order express the same policy. Operational controls must detect partial propagation and provider-specific behavior before stale content reaches a wider audience. Purpose and scope Multi-CDN changes cache behavior because different networks fetch, store, and expire objects using different rules and clocks. The goal is that users receive the same bytes for the same URL regardless of the serving CDN and that changes reach users in a controlled and explainable way. The guidance applies to static assets and dynamic responses that allow caching. It also covers the surrounding systems that push and purge content. ...

Synopsis An origin that serves multiple CDNs must tolerate their combined fetch patterns and different failure behavior. Topology, shielding, authentication, cache keys, deployment order, and failover controls determine whether content remains correct when traffic moves. Role of the origin in multi-CDN The origin is the source of truth for content and APIs. In a multi-CDN setup more than one provider will fetch from it. The design must handle higher fan in, different retry behaviors, and different cache semantics without breaking correctness. It should also keep the number of variables low so that problems are diagnosable during incidents. ...