Problem
Repeated computation or database queries for same data wastes resources and adds latency.
scalingestablished · low operational burden
Caching
Also known as: cache, redis, memcached, cdn, local-cache
Intent
Store frequently accessed computed or fetched data in fast storage to reduce latency and downstream load.
Forces
- •Read-heavy workloads with skewed access patterns (hot keys)
- •Downstream latency or cost must be reduced
- •Cache invalidation is hard (stale data risk)
- •Cache memory is limited (eviction policy needed)
Solution
✓ When to Use
- •Hot data: config, reference data, computed aggregates
- •Expensive computations: recommendations, ML inference
- •Downstream protection: reduce DB/third-party load
✗ When Not to Use
- •Write-heavy, low-read data
- •Strong consistency required (financial balances)
- •Data larger than cache memory (thrashing)
Pros
- +Orders of magnitude latency reduction
- +Protects downstream from load spikes
- +Enables read scale without DB scale
Cons
- −Stale data: TTL expiry, invalidation failures
- −Thundering herd: cache miss storm on hot key expiry
- −Cache inconsistency across instances (distributed cache)
- −Operational: eviction, memory pressure, hot keys
Cost Profile
Infrastructure
Low (local) to Medium (Redis cluster)
Operational
Medium — TTL tuning, invalidation, monitoring hit rate
Cognitive
Low — intuitive concept
Failure Modes
Cache avalanche: mass expiry → DB overload
Cache stampede: hot key miss → concurrent DB queries
Stale reads: invalidation missed, TTL too long
Memory pressure: eviction of hot keys, cascade misses
Split-brain: local caches diverge
Real-World Examples
Alternatives
- read-replica
- materialized-view
- query-optimization
- precomputation
Related Patterns
- cache-aside
- read-through
- write-through
- thundering-herd
- cache-invalidation
Competency Domains
data statescalingreliability opseconomics evolution