stale-guardlisted

# stale-guard Every cache is a bet that a copy will be kept consistent with its source by *discipline* — there's no referential integrity for Redis. The bet is lost quietly: a new write path skips the invalidation the original author wired up, a key forgets one dimension, and now users see stale data — or worse, *each other's* data. These bugs feel "random" (they depend on cache state) and get closed as unreproducible. The review is systematic instead: enumerate the copies, then prove two invariants for each. ## Step 1: enumerate every copy of the truth More than the obvious Redis calls: in-process memoization and `@lru_cache`, HTTP/CDN caching headers, denormalized columns (`post.comment_count`), materialized views, search indexes (Elastic mirroring the DB), precomputed aggregates, edge/session caches, client-side stores fed by the API. For each: what is the **source of truth**, and what is the copy's **staleness budget** — the maximum age at which serving it is still *correct* (not just tolerable)? "Whatever the TTL happens to be" is not a budget, it's an accident. ## Step 2: invariant A — every write path invalidates This is where caching correctness actually dies. For each copy, list **every** write path that mutates its source — not just the service's main update endpoint: admin panels, bulk imports, migrations and backfills, *other services* writing the same table, DB triggers, manual ops SQL. Then check each one updates or invalidates the copy. - The classic fail