The origin is down. Should the CDN show yesterday's page or return an error?

Interview question. A marketplace serves public product descriptions through a CDN. The origin sometimes fails for a minute. Marketing wants the page to remain available, finance worries about incorrect prices, and security insists revoked content must not reappear. Explain HTTP freshness, revalidation, stale-while-revalidate, and stale-if-error with an explicit contract for each content type.

Take a page stored at noon with Cache-Control: public, max-age=60, stale-while-revalidate=30, stale-if-error=300. At 12:00:40, assuming its computed current age is forty seconds, the cached copy is fresh and may be returned without contacting the origin. At 12:01:10 the copy is stale by ten seconds. If a cache implements the extension and no conflicting directive forbids it, it may return the existing body while checking for a newer representation in the background. At 12:02:00, the thirty-second stale-while-revalidate allowance is over. That does not automatically mean stale content can never be served. A qualifying error may still permit the cached representation within the configured stale-if-error window.

That is the mechanism, but it is not a universal promise that any CDN behaves identically. Browser, proxy and CDN caching are governed by HTTP semantics plus implementation and configuration. Some CDNs expose separate edge TTL controls. Others handle soft purge, validation, and origin failures differently. In production I would write tests for the exact CDN configuration, including what happens when a response includes s-maxage, must-revalidate, no-cache, or provider-specific overrides. An apparently harmless addition of s-maxage can change whether a shared cache is allowed to serve stale content.

Revalidation often avoids retransmitting the complete object. If an origin provided an ETag, a cache may send If-None-Match. The origin can return 304 Not Modified, and the cache updates freshness metadata without downloading all bytes again. If the resource changed, the origin returns a new representation. This matters with large pages and images because the bandwidth cost of validating content can be much smaller than fetching it. Still, an ETag says something about representation equivalence, not about whether a user has permission to see it.

The more useful interview question is which content deserves this behavior. For a public product description, a few minutes of stale information may be acceptable. A stale image or blog page may be preferable to an error during an outage. For a payment balance, available inventory count, revoked document, or security rule, stale content may violate the actual product contract. Some responses should use private or no-store, or require revalidation before reuse. Do not declare every public GET safe simply because it is read-only. Returning an outdated price during checkout can be a correctness issue even if browsing the same outdated product card is tolerable.

A common mistake is to configure a global stale allowance and then attempt revocation with a purge request alone. A hard purge can remove a cached response, but propagation is not necessarily instantaneous at every cache a client might reach, and browser caches may exist outside the CDN's direct control. For sensitive content, a cache hit must never become an authorization bypass. Versioned URLs and short-lived capabilities help some cases, but emergency revocation may require online checks or content that was never stored in a shared cache.

Imagine the origin becomes unavailable when the cached page is 200 seconds old. With the example values, it is stale by 140 seconds. That age is beyond the 30-second background-revalidation window but within the 300-second error allowance. It may be acceptable to serve the old product description if the origin failure qualifies and no stricter directive applies. The same response should not be treated as safe after it is stale by 400 seconds. Stale windows describe maximum permitted reuse under specified conditions, not indefinite availability insurance. They are also not an excuse for an origin that has silently stopped publishing updates but still returns healthy responses.

There is another useful failure test: an origin returns HTTP 200 with an old body because its own upstream feed is frozen. The CDN sees a successful validation path and cannot infer business freshness from the status code alone. Put source-version or publish-time signals into the data pipeline and alert separately when those signals stop advancing.

In an incident I would expose the original publication timestamp, cache age, revalidation outcome, stale reason, origin error status, and user-visible freshness label where useful. An availability chart showing successful HTTP 200 responses is not enough if every page is hours old. Separate the SLO for serving a page from the freshness SLO for its data. Otherwise the CDN makes the outage look smaller by hiding the thing customers care about.

The answer I want in an interview is a policy, not a list of headers. State what may be stale, for how long, under which errors, and which information must never be stale. Implement that policy through verified HTTP behavior and tests. Availability is valuable only when we know which correctness guarantees we are giving up to obtain it.