Caching

A cache key decides whether two requests may reuse the same stored response. A typical CDN starts with the request scheme, host, path, and query string. It may also include selected headers or cookies. The Vary response header is the HTTP mechanism that tells a cache which request headers selected a representation. The safe goal is simple: requests that should receive the same bytes should share a key, while requests that require different bytes must not collide. A key that is too narrow can expose the wrong response. A key that is too broad creates many variants, lowers the cache hit ratio , and increases origin traffic. ...

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. Quick answers max-age sets freshness for private and shared caches. s-maxage overrides max-age in a shared cache such as a CDN. It does not change the browser’s freshness lifetime. Vary tells a cache which request headers selected the response. Each meaningful value can create a separate representation. Vary: * prevents normal reuse because the cache cannot prove that a later request is equivalent. no-cache allows storage but requires validation before reuse. no-store prohibits storage. 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 Multi-CDN caches do not become consistent automatically. The same request can produce different objects when providers use different cache keys, default TTLs, purge semantics, or origin headers. Consistency requires one explicit policy, equivalent provider configurations, safe deployment order, and verification at more than one edge. Operational checklist Define one cache-key specification for hosts, paths, query strings, headers, and cookies. Return explicit Cache-Control and validator headers from the origin. Use content-addressed or versioned URLs for static assets. Keep temporary 404 and 5xx caching short and consistent. Translate one purge intent into the narrowest supported operation at every provider. Record provider request identifiers, completion state, and elapsed time. Verify response bytes, Age, validators, and cache-status headers from representative regions. Keep old immutable assets available during rollback. Test the policy whenever a provider or origin layer changes. 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. ...