What do the HTTP response directives `Cache-Control: stale-while-revalidate=60` and `Cache-Control: stale-if-error=86400` instruct a cache to do, and what risk does each accept in exchange for what benefit?

## The problem at the moment of expiry With plain `max-age=60`, the request that arrives at second 61 is the unlucky one: it blocks on a full origin round trip while every earlier request was served from cache in microseconds. At scale this is worse than unfair — if many cache entries share a lifetime, they expire together and produce a synchronised burst of origin traffic, the cache stampede. And if the origin happens to be down at that moment, a perfectly good stored copy is discarded in favour of an error page. RFC 5861 adds two directives that address these separately. ## stale-while-revalidate=N For N seconds after the freshness lifetime ends, the cache is permitted to serve the stored (now stale) response **immediately** and start revalidation in the background. The requesting client waits for nothing. When the revalidation completes, the stored response is replaced and its freshness clock restarts, so subsequent users see fresh content. Effects worth naming: - **Latency becomes uniform.** No user ever pays the origin round trip for this resource, so the p99 stops spiking at expiry boundaries. - **Origin load is smoothed.** In a shared cache one background revalidation serves the whole population behind that node, instead of every concurrent request racing to the origin. - **The effective maximum age becomes `max-age + stale-while-revalidate`.** That is the number to state when someone asks how stale content can get. If nobody requests the resource during the stale window, the entry simply expires out of the window and the next request revalidates synchronously. A subtlety: the guarantee holds per cache node. A CDN with many edge nodes and a cold node still incurs a synchronous fetch, so this is a complement to request coalescing at the edge, not a replacement. ## stale-if-error=N This one triggers only on failure. If the cache tries to revalidate and gets a connection error, a timeout, or a 500, 502, 503 or 504, it may serve the stale stored response for up to N seconds past expiry rather than surfacing the error. It is availability insurance, and the N is usually much larger than for `stale-while-revalidate` — hours or a day — because the point is to ride out an incident. The judgement call is which failure is worse: a user seeing yesterday's content or a user seeing an error page. For marketing pages, documentation, catalogue listings and navigation, stale wins overwhelmingly. For anything where acting on stale data has consequences — prices at checkout, stock levels at the point of commitment, an authorization decision — the error is the honest answer, and hiding the outage may be actively harmful. A second-order risk: serving stale during an outage removes the user-visible symptom, which can delay detection if your alerting is based on user-facing errors rather than on origin health and revalidation-failure rates. Instrument the cache's stale-serve counter and alert on it. ## How they combine and interact A typical edge policy reads `Cache-Control: public, max-age=60, stale-while-revalidate=30, stale-if-error=86400`: fresh for a minute, then served instantly while refreshing for thirty seconds, and held for a day if the origin is unavailable. Interactions to remember: - **`must-revalidate` disables both.** It explicitly forbids serving a stale response, so combining them is contradictory; `must-revalidate` wins. - **`no-store` makes both irrelevant**, since nothing is stored. - **`no-cache` makes both irrelevant for reuse**, since every use requires successful revalidation. - **Support is uneven.** Both are widely implemented in CDNs; browser support for `stale-while-revalidate` exists but is less consistent, and `stale-if-error` less so still. Treat them as best-effort optimisations rather than guarantees you can build correctness on — and note that a CDN can implement equivalent behaviour through its own configuration regardless of the header. ## How to reason about the value of N Pick `stale-while-revalidate` from the shape of your traffic: it needs to be long enough that a background revalidation completes comfortably, so a few multiples of your p99 origin latency. Pick `stale-if-error` from your incident profile: long enough to cover a realistic recovery, short enough that genuinely abandoned content does not linger. And state the resulting worst-case age explicitly in the service's documentation, because you have converted an accident into a policy and someone downstream needs to know the number.