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 freshness requirements, miss behavior, write cost, and failure risk.
In architecture conversations, that helps you discuss cache placement, acceptable staleness, and operational failure modes as real design choices rather than 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
Choose invalidation by business semantics: synchronous updates, event-driven invalidation, TTL, or hybrid versioning.
Stampede Protection
Prevent stampede with TTL jitter, single-flight, background refresh, and controlled origin fan-out.
Interview Framing
Demonstrate you understand not only read acceleration, but also consistency impact and operational risks.
Pattern
Cache-Aside Pattern
Canonical reference for cache-aside and the trade-offs that matter in production.
Choosing a caching strategy is really about deciding where freshness matters, what should happen on a miss, and how much operational complexity you are willing to carry in production.
Cache-Aside, Read-Through, Write-Through, and Write-Back solve different problems: some keep the read path simpler, some make read-after-write more predictable, and some trade stronger write guarantees for much cheaper writes.
Before choosing, define where the source of truth lives, how invalidation works, what cache hit rate is good enough, how TTL should be set, and how you will prevent miss storms during expiry waves or failures.
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.
How to Choose a Strategy
| Strategy | Read latency | Write latency | Consistency | Complexity | Best fit |
|---|---|---|---|---|---|
| Cache-Aside | Low on a hit, higher on a miss | Low: the database is updated separately from cache | Depends on how quickly invalidation propagates | Low / medium | General read-heavy scenarios |
| Read-Through | Stable because the cache layer loads data itself | Depends on the chosen write policy | Depends on how the write path is designed | Medium | Shared infrastructure cache layers |
| Write-Through | Low | Higher: cache and database are updated synchronously | High after successful write | Medium / high | Flows where read-after-write matters |
| Write-Back | Low for already warmed data | Very low for the client | Deferred, with stronger durability requirements | High | Write-heavy flows with batch flush |
Practical Guidance
What to do
- Start by defining where stale data is acceptable and where reads must immediately reflect writes.
- Treat invalidation and eviction as separate design problems, not as afterthoughts.
- For Write-Back, rely on durable buffering and idempotent flush behavior.
- Add miss-storm protection: request coalescing, small TTL variance, and background refresh for hot keys.
Common mistakes
- Caching without a clear invalidation strategy and lifetime policy.
- Using Write-Back for critical financial data without a durable journal or queue.
- Trying to cache everything instead of focusing on expensive reads and hot keys.
- Leaving the system unprotected against large miss storms and request collapse.
- Ignoring cache hit rate, p95/p99, and how often stale data is served.
Checks Before Rollout
Short selection rule: if predictability and simplicity matter most, start with Cache-Aside; if strict read-after-write matters, look toward Write-Through; if the main bottleneck is the write path and deferred consistency is acceptable, choose Write-Back with a reliable flush pipeline.
Related chapters
- Design principles for scalable systems - helps explain when cache really lowers latency and when it mainly adds freshness and consistency problems.
- Load balancing algorithms - helps explain how key locality and traffic distribution affect cache hit rate and hot-key pressure.
- Redis: in-memory database and architecture - covers the operational cache layer: entry lifetime, eviction, durability, and practical production constraints.
- Service Discovery - shows how to discover and refresh cache/backend node pools to keep read/write paths stable in production.
- URL Shortener (TinyURL) - shows a concrete case where cache-aside and warmup strategy directly affect latency and cost.
- Content Delivery Network (CDN) - extends the discussion to edge caching, invalidation, and multi-layer cache architecture.
- Multi-region / Global Systems - adds regional replication concerns and cache consistency rules across data centers.