When an invalidation cannot be guaranteed to reach every stored copy, how do you decide which copies to trust it for and which to bound with a short window?

## Two truths at once The characteristic incident in this area is not `everything is stale`. It is **partial reach**: the invalidation ran, it succeeded, and it landed on some of the copies of the changed value. The result is a site that contradicts itself — a detail page showing the new price while a listing shows the old one, a first load disagreeing with what a visitor sees after clicking around, one visitor seeing the update and their colleague not. This is worse than uniform staleness for reasons that are about people rather than systems: - it is **irreproducible** — whoever investigates hits a copy that happens to be correct; - it destroys the reader's model of the product, because no explanation they can form covers what they saw; - it makes every subsequent report untrustworthy, since nobody can say which surface was which. So the design goal is not maximum freshness. It is **consistency of the promise across surfaces**, at whatever level of freshness you chose. ## The three questions, asked per copy For each place a copy of a value can end up, ask: 1. **Can I address it?** Is there a handle — a path, a label — that a purge can match, or is the copy anonymous? 2. **Do I learn that the purge applied?** A local store answers synchronously. A remote one may accept the request and apply it later. Something in front of your origin may or may not report success. A payload already delivered to a visitor's open tab cannot be reached at all; only a fresh request replaces it. 3. **What is the worst case if the signal is lost?** If the answer is `stale until the window ends`, that window is what you are actually promising. Any copy that fails question 1 or 2 must not be carrying a freshness guarantee based on signals, no matter how reliable the signal appears in testing. ## Turning that into a policy | content class | tolerable staleness | who carries the promise | |---|---|---| | money, entitlements, permissions | none | do not cache the value; derive it per request | | inventory, availability, status | seconds to a minute | a short window; treat signals as a bonus | | editorial and catalogue content | minutes | signals, with a window as the backstop | | marketing pages, documentation | hours | a long window; signals for editor satisfaction | Two rules make the table hold in practice. First, **align the surfaces**: if one copy of a value can only be bounded by a two-minute window, giving another copy a one-second window buys nothing except the disagreement between them — a uniformly two-minute-old site is better than a self-contradictory one. Second, **the weakest link sets the promise**; the guarantee you may state publicly is the worst reachable copy's worst case, not the best one's. ## Verify reach, or you do not have it An invalidation strategy nobody measures is a habit, not a mechanism. The cheap instrument is an end-to-end canary: 1. write a recognisable value through the real write path; 2. poll every surface that should reflect it — server-rendered output, an in-app navigation, the machine-readable feed, a request that goes through whatever sits in front of the origin; 3. record time-to-convergence per surface; 4. alert on any surface that fails to converge inside its stated window. The output is the number this whole discussion is about: not `did the purge return success` but **how long each surface actually takes to tell the truth**. It also catches the two failures nobody else catches — a surface that never converges (a dependency nobody declared) and a surface that converges only because its window elapsed (a signal that has been silently broken for months). ## The judgment calls a lead owns - **Where to spend.** Extending reach to an additional tier costs engineering time and operational risk. Shortening a window costs capacity. Price both against the cost of staleness for that content class, and be willing to say that hours-old marketing copy is fine. - **Uniform versus tiered windows.** Uniform is easier to explain and keeps surfaces in agreement; tiered wins real capacity on high-traffic routes. Choose deliberately, and write it down. - **What is simply not cacheable.** The mature answer to `this must never be stale` is not a cleverer invalidation scheme; it is a value that is computed per request. Deciding which values those are is an architectural call, not an optimisation. - **Who is paged.** When propagation breaks, the failure is silent. Somebody must own the convergence metric, or the first report will come from a customer comparing two pages. ## The mental model Invalidation makes the common case fast; the window is what you promise. Say the promise out loud per class of content, check that every surface can keep it, and prefer a site that is consistently slightly behind over one that is fresh in places.