staff-engineering-skills-cache-invalidation
Installation
SKILL.md
Cache Invalidation Trap
You added a cache for performance. Now users see stale data. Before caching anything, ask: when the source data changes, how does every copy get updated or discarded?
The Fundamental Problem
A cache is a copy, and copies diverge from the source. Every cache creates a consistency obligation: when the source changes, you must update or discard the copy. If you can't answer "how does this cache learn that the source changed?", you don't have a caching strategy -- you have a stale data bug with a variable delay.
The Cache Hierarchy
Data passes through multiple cache layers; invalidating one doesn't invalidate the others. Invalidate the application cache but not the CDN (or the CDN but not the browser), and the stale layer keeps serving old data.
| Layer | Control | Invalidation | Risk |
|---|---|---|---|
| Browser cache | Limited (Cache-Control headers) | Can't force purge from server | Stale until user refreshes |
| CDN | Purge API, surrogate keys | Propagation delay (seconds) | Millions served stale data |
| Reverse proxy | Full control | Direct purge | Stale responses after deploy |
| Application cache (Redis, in-memory) | Full control | Event-driven or TTL | Process-local caches diverge across instances |
| ORM/query cache | Framework config | Often implicit, hard to invalidate | Stale reads after direct DB writes |