Cache Invalidation Review¶
Review protocol — instantiates Change-Scoped Revalidation
Walks the store of previously-derived results after a change and rules, item by item, which are now stale and must be recomputed versus which may still be trusted.
Most of what a system "knows" at any moment is not computed fresh — it is stored: cached query results, memoized figures, pre-approved documents, decisions already signed off. When something upstream changes, all of that stored work is suddenly of unknown validity. Cache Invalidation Review is the protocol that goes through the store of previously-derived results and rules on each one: still trustworthy, or stale and due for recomputation? Its defining move is a default-keep presumption — a stored result stands until a specific invalidation rule says otherwise — which is exactly what makes it cheap and exactly what makes it dangerous. It is a keep-or-drop gate on retained work, not a method for discovering what a change affects (that is upstream of it) nor for re-deriving the items it drops (that is downstream).
Example¶
A data platform serves dozens of dashboards from materialized views — expensive queries whose results are precomputed and stored so dashboards load instantly. One morning an analytics engineer redefines a core orders table, splitting one status column into two. Recomputing every view would take hours and lock resources the business needs by 9am; trusting all of them risks serving dashboards silently built on a column that no longer means what it did. The Cache Invalidation Review is the step in between. Going view by view, it applies an invalidation rule keyed to lineage: any stored view whose definition reads the changed column — directly or through an intermediate view — is marked stale and queued to recompute; views with no path to orders.status keep their default-valid presumption and are served as-is. The output is a short partition — "these ≈9 of 61 views recompute now, the rest stand" — and, for each invalidated view, a pointer to the authoritative source it must be rebuilt from. The hours-long full refresh collapses into a nine-view recompute, and no dashboard is served on a definition that moved.
How it works¶
- It enumerates the retained store, not the change — its unit of work is a stored result, and it asks one yes/no validity question about each.
- The presumption is keep: silence from the invalidation rule means the item stands. This inverts the usual "recheck everything" default and is the entire source of its economy.
- The invalidation rule is the whole game. It must fire on every genuinely-stale item without firing on everything (which would defeat the point), so rules are keyed to lineage/dependency or to a version or timestamp watermark rather than to guesswork.
- Each invalidated item carries a pointer to its source of truth — the authoritative place it will be rebuilt from — so dropping stays cleanly separable from recomputing.
Tuning parameters¶
- Invalidation aggressiveness — how readily the rule fires. Loose rules keep more stale results (fast, unsafe); tight rules invalidate liberally (safe, expensive). This is the central dial and the one most often left too loose.
- Rule basis — lineage/dependency-keyed vs. a coarse time-to-live vs. a version watermark. Dependency-keyed is precise but needs an accurate map; a TTL is crude but needs almost nothing.
- Granularity — invalidate a whole store or individual entries. Fine granularity spares valid work but costs bookkeeping.
- Recompute timing — invalidate-then-recompute-now vs. mark-stale-and-recompute-on-next-read. Lazy recompute defers the cost to whoever actually needs the value.
- Review trigger — run on every change, on a batch of changes, or on a fixed cadence.
When it helps, and when it misleads¶
Its strength is that it is what makes retaining prior work safe enough to be worth it: it lets a system keep the 90% a change didn't touch without pretending the change touched nothing, and it separates "is this stale?" from the expensive rebuild so recomputation only hits items that genuinely moved.
Its failure mode is that the hard part is genuinely hard — a rule that under-fires serves stale reads that look authoritative, and stale data is worse than obviously-missing data because nobody double-checks it.[n1] The classic misuse is running the review to justify keeping rather than to test: tuning the invalidation rule to almost never fire so the recompute bill stays low, then citing the clean review as evidence the cache is fresh. The discipline that guards against it is to derive the invalidation rule from the actual dependency structure rather than from convenience, and to keep an independent backstop — a periodic full recompute, or Boundary Escape Sampling over the retained set — so systematic under-firing is caught rather than trusted.
How it implements the components¶
Cache Invalidation Review fills the retain-side machinery of the archetype — the components that decide what may persist, not what is affected:
persistence_presumption— its default-keep stance is the persistence presumption made operational: a retained item stands until proven stale.invalidation_rule— the review's core logic; the rule that decides, per item, whether that presumption is overridden.source_of_truth_reference— for each invalidated item, the authoritative source it must be re-derived from, recorded so drop and rebuild stay separable.
It does not discover which items a change reaches — that closure is computed by Dependency Closure Traversal — nor re-derive the invalidated items (Regression Test Suite / Selective Revalidation Worklist), nor test whether the retained set leaked (Boundary Escape Sampling).
Also instantiates¶
Dynamic Subproblem Reuse — Reuse of solved subproblems is only worth the trouble if the memoized store can be trusted, and its entire efficiency gain is destroyed the moment a stored partial answer survives a change to the assumptions it was computed under. Cache Invalidation Review is the maintenance discipline that keeps a memoization cache or reusable-solution library safe to draw from: when an input, constraint, or dependency shifts, it walks the stored answers and retires the ones whose equivalence no longer holds, so a reuse key never hands back a partial solution computed for conditions that have since moved. Where the primary facet frames the review as a one-shot revalidation gate fired by a specific change event, here it is the ongoing invalidation component that lets a reuse structure stay trustworthy across time — the difference between a cache that accelerates work and one that quietly propagates stale, misapplied precedent into every larger solution it feeds.
Related¶
- Instantiates: Change-Scoped Revalidation — it operationalizes the archetype's "retain the rest by a defeasible persistence presumption" half.
- Consumes: the change signal and dependency lineage (from Data Diff and Merge Tool / Dependency Graph) that its invalidation rule keys on.
- Sibling mechanisms: Truth-Maintenance System · Boundary Escape Sampling · Persistence Exception Register · Impact Analysis · Dependency Closure Traversal · Change Impact Report · Regression Test Suite · Requirements Traceability Matrix · Dependency Graph · Data Diff and Merge Tool · Selective Revalidation Worklist
Editorial Notes¶
Form Classification¶
Form family: Assessment, Review & Assurance
Rationale: Walks the store of previously-derived results after a change and rules, item by item, which are now stale and must be recomputed versus which may still be trusted, making its operative form a bounded evaluation of existing evidence or work that produces a finding or disposition.
Independent corroboration: The frozen evidence defines Cache Invalidation Review as 'Walks the store of previously-derived results after a change and rules, item by item, which are now stale and must be recomputed versus which may still be trusted', so its operative form is Assessment, Review & Assurance.
Review outcome: Independent reviewer agreement; high confidence.
Origin Attribution¶
Primary origin: Computer Science & Software Engineering
Origin pattern: Single lineage
Present-day reach: Specialized
Rationale: Cache invalidation is a canonical computer-systems problem: changes must be mapped to derived entries whose prior results can no longer be trusted.
Review resolution: Computer science is the agreed primary lineage. Reviewing invalidation triggers, dependencies, ownership, and stale-read failures is a specialized extension of cache-coherence practice, not a broad-origin Encyclopedia synthesis.
Review outcome: Reconciled after independent review; high confidence.
Notes¶
Cache Invalidation Review can only rule on items already in the store. A change that should create a brand-new obligation — something that never existed to be cached — is invisible to it, because there is no stale entry to invalidate. That blind spot is why it pairs with an affected-scope analysis and an escape check, which look at what a change creates and reaches, not only at what it invalidates.
[n1] The well-known quip, attributed to Phil Karlton, that the two hard problems in computer science are cache invalidation and naming things. It is invoked here for its accurate half: deciding exactly when a stored result has gone stale is hard, and getting it wrong yields authoritative-looking stale reads. ↩