Every Cache Creates Invalidation Complexity
“A cache is not a read optimization: it is a consistency contract. The cost of that contract is invalidation complexity: ensuring that every path that writes data also invalidates or updates every cache that reflects that data. ”
Caches improve read throughput but introduce a consistency dual: every write to the primary data store creates an obligation to update or invalidate the cache. Miss a write path, and users see stale data. Invalidate too aggressively, and the cache provides no protection. Invalidate incorrectly (race condition between write and invalidation), and users see a brief inconsistency window. The cache is only as consistent as the most obscure write path that touches the cached data.
Why It Matters
The phrase "just add a cache" significantly understates the operational commitment. Adding Redis to a PostgreSQL API requires: defining what data is cached, defining TTLs for each cache key pattern, defining invalidation triggers for every write path that modifies cached data, handling cache stampede under high load, and monitoring cache hit rate as a correctness metric: not just a performance metric. Cache miss rate is a consistency signal: sudden hit rate drops indicate stale key patterns or incorrect invalidation logic.
Failure Modes
- ·Write path omission: a new write path fails to invalidate the cache, causing permanent staleness
- ·Race condition: write followed by cache invalidation, interrupted by a read between the two operations
- ·Cache stampede: cache miss under high load causes thousands of simultaneous primary reads
- ·TTL-induced staleness: long TTLs cause extended stale read windows during high-write-volume periods
- ·Cache size eviction: LRU eviction under memory pressure silently invalidates hot keys
Amplification Risks
- ⚡Cache stampede: simultaneous cache miss under load creates N-fold amplification of primary read traffic
- ⚡Invalidation cascade: large-key invalidation under high write volume causes extended cache rebuild latency
- ⚡Memory pressure feedback: cache eviction causes hit rate degradation, which increases primary load, which increases memory pressure
Temporal Behavior
- ⟳TTL expiry creates predictable staleness windows: but expiry timing under load is non-uniform
- ⟳Cache stampede is a temporal event: it occurs when many cache entries expire simultaneously
- ⟳Write-through invalidation eliminates the staleness window but adds write latency
Boundary Implications
- ◈The cache creates an invalidation boundary: correctness depends on the boundary being maintained across all write paths
- ◈TTL-based consistency boundaries are weaker than write-through boundaries
- ◈Distributed caches create coherence boundaries across cache nodes
Topology
- ·Cache nodes in topology create invalidation edges: every write path must include cache invalidation
- ·Cache miss paths create fallback load on primary stores: under high miss rates, cache amplifies primary load
- ·Cache nodes with no explicit invalidation paths are consistency risks
Scaling
- ·At high write volume, cache invalidation becomes a write amplification source
- ·Distributed caches require cache coherence coordination across nodes
- ·Cache hit rate degrades under high-write workloads: the assumption of write-rarely must be validated per workload
Resilience
- ·Cache failure should be a graceful degradation event: read traffic falls back to primary, which must be sized for it
- ·Without primary capacity planning for cache-miss scenarios, cache failure causes primary overload
- ·Cache stampede tests should be part of load testing: they reveal primary capacity requirements
Governance Implications
- ·Every new write path must be reviewed against cached data it might invalidate
- ·Cache invalidation coverage must be tested explicitly: not assumed from TTL expiry
- ·Cache TTLs must be set as explicit consistency SLAs, not chosen for performance alone
Evolution Implications
- ·Adding new write paths to cached-data models requires explicit cache invalidation analysis
- ·Schema changes to cached entities require cache key strategy review
- ·Removing caches requires primary read path capacity planning to handle returning load
Mitigation Patterns
- →Use write-through cache invalidation for consistency-sensitive data, TTL for tolerance-permitting data
- →Build a cache invalidation coverage map: every write path mapped to every cache key it must invalidate
- →Implement probabilistic early expiry (jitter on TTL) to prevent cache stampede under uniform TTL patterns
- →Monitor cache hit rate as a correctness metric: sudden drops indicate invalidation logic gaps
- →Plan primary read capacity for cache-miss scenarios: this is the true resilience floor
Cross-References