Caching almost always buys speed at the price of staleness, invalidation complexity, and a more fragile operating loop.
The chapter compares Cache-Aside, Read-Through, Write-Through, and Write-Back through read-after-write semantics, cache miss behavior, stampede protection, recovery after failure, and the cost of maintaining a source of truth across layers.
In architecture conversations, it helps you treat cache placement, staleness tolerance, and cache-layer failure modes as real design decisions rather than as the automatic move of 'let's add Redis.'
Practical value of this chapter
Cache as contract
Treat cache policy as a product contract: define where stale reads are acceptable and where strict freshness is required.
Invalidation strategy
Choose invalidation by business semantics: write-through, event-driven invalidation, TTL, or hybrid versioning.
Anti-storm controls
Prevent stampede with TTL jitter, single-flight, background refresh, and controlled origin fan-out.
Interview confidence
Demonstrate you understand not only read acceleration, but also consistency impact and operational risks.
Pattern
Cache-Aside Pattern
Canonical description of a caching pattern with practical production trade-offs.
The caching strategy determines not only latency, but also consistency boundaries, recovery complexity, and behavior under traffic spikes. In production, teams usually combine multiple approaches: for example, cache-aside for read paths and write-through for critical entities with strict read-after-write requirements.
Four Core Strategies
Cache-Aside
The application controls cache reads and loads data from DB on misses.
Read Path
App
read(key)
Cache
GET key
DB
SELECT on miss
Cache
SET key
App
return value
Write Path
App
update(key)
DB
WRITE source of truth
Cache
invalidate/update key
App
ack
What happens
- Reads go to cache first; on a miss, data is loaded from DB.
- After a miss, the app warms cache for subsequent requests.
- Writes go to DB first, then cache is invalidated/updated to control stale data.
Risk: Invalidation is critical; weak invalidation quickly increases stale-read rate.
Quick Strategy Selection
| Strategy | Read latency | Write latency | Consistency | Complexity | Best fit |
|---|---|---|---|---|---|
| Cache-Aside | Low on hit, higher on miss | Low (DB-only + invalidate) | Eventual (depends on invalidation) | Low/medium | General-purpose read-heavy services |
| Read-Through | Stable through a unified cache layer | Depends on paired write policy | Depends on write-side strategy | Medium | Platform cache layers |
| Write-Through | Low | Higher (synchronous double write) | High after successful write | Medium/high | Read-after-write critical flows |
| Write-Back | Low | Very low | Eventual, complex recovery | High | Write-heavy ingestion |
Practical Rules
What to do
- Define freshness/staleness SLA before selecting a strategy.
- Design cache invalidation and eviction policy as separate concerns.
- For write-back, use durable buffer plus idempotent flush pipeline.
- Add cache-stampede protection (single-flight, TTL jitter).
Common mistakes
- Caching without an explicit invalidation strategy and TTL policy.
- Using write-back for critical financial data without durable queue/journal.
- Caching everything instead of focusing on hot keys and expensive queries.
- Ignoring stampede/thundering herd during large cache-miss waves.
- Not tracking hit rate, p95/p99 latency, and stale-read rate.
Mini Implementation Checklist
Short selection rule: if predictability and simplicity matter most, start with Cache-Aside; if strict read-after-write is critical, choose Write-Through; if write throughput is the priority and eventual consistency is acceptable, use Write-Back with a reliable flush pipeline.
Related chapters
- Design principles for scalable systems - defines baseline latency/cost trade-offs where caching strategy delivers the main practical benefit.
- Balancing algorithms: Round Robin, Least Connections, Consistent Hashing - helps explain how key locality and traffic distribution affect cache hit rate and hot-key pressure.
- Redis: overview and practical aspects - covers the common cache runtime layer: TTL, eviction policies, persistence, and operational constraints.
- Service Discovery - shows how to discover and refresh cache/backend node pools to keep read/write paths stable in production.
- URL Shortener (caching strategy) - demonstrates an applied scenario where cache-aside and TTL choices directly affect latency and cost.
- CDN and cache invalidation - extends the topic to edge caching, purge/invalidation mechanics, and multi-layer cache architecture.
- Multi-region / Global Systems - adds regional replication concerns and cache consistency rules across data centers.