Caching is the single biggest performance lever in any system. But "just add a cache" is a hand-wave — the strategy determines consistency, write amplification, and failure modes. Cache-aside, write-through, write-back, and read-through each have fundamentally different trade-off profiles.
Interviewers probe this because cache invalidation is one of the two hard things in computer science. Knowing which strategy to pick — and articulating why — separates L4 from L5 answers.
02
Head-to-head comparison
Strategy
Write path
Read path
Consistency
Complexity
Best for
Cache-aside (Lazy)
App writes to DB only; invalidates/deletes cache entry
App checks cache → miss → reads DB → populates cache
Eventual (stale window between write and next read)
Low — app controls both paths
Read-heavy, tolerates brief staleness
Write-through
App writes to cache AND DB synchronously
Always read from cache (populated on write)
Strong — cache always has latest
Medium — dual write on every mutation
Read-heavy with strict consistency needs
Write-back (Write-behind)
App writes to cache only; cache async flushes to DB
Always read from cache
Weak — data loss risk if cache crashes before flush
High — need flush queue, retry, ordering
Write-heavy, latency-sensitive (gaming, counters)
Read-through
App writes to DB; cache auto-loads on miss
Cache intercepts reads; loads from DB on miss transparently
Eventual (same as cache-aside but cache manages itself)
Low — cache library handles loading
Simplify app code, uniform read pattern
Key insight: Cache-aside puts the app in control. Write-through and read-through let the cache layer manage itself. Write-back trades durability for speed. Most production systems use cache-aside because it's simplest to reason about.
03
Decision flowchart
Follow this decision tree based on your read:write ratio and consistency needs:
Read:write ratio > 10:1 and you tolerate brief staleness? → Cache-aside. This is the default. Simple, battle-tested, used by most web applications.
Read:write ratio > 10:1 but need strong consistency? → Write-through. Every write updates cache synchronously, so reads always see latest. Higher write latency but zero stale reads.
Write:read ratio high, latency-critical? → Write-back. Absorb write bursts in the cache, flush to DB asynchronously. Accept the durability risk. Use for counters, leaderboards, real-time analytics.
Want to simplify application code? → Read-through. The caching layer handles DB loading transparently. Works well with cache libraries like Guava, Caffeine, or managed services like DAX.
The interview answer: "Cache-aside for most read-heavy workloads. Write-through when you need cache consistency. Write-back for write-heavy latency-sensitive paths. Read-through to simplify the app layer."
04
When to pick what — deeper context
Cache-aside — the industry default
Used by virtually every web app with Redis or Memcached. The pattern: read → check cache → miss → query DB → write to cache with TTL. On write: update DB, then delete (not update) the cache key. Why delete instead of update? Because delete-on-write avoids race conditions where two concurrent writes leave the cache with stale data.
The classic bug: app writes to DB, then cache delete fails (network blip). Now cache has stale data until TTL expires. Mitigation: short TTLs + eventual consistency acceptance, or use a CDC stream to invalidate.
Write-through — consistency at a cost
Every write goes through the cache to the DB. This guarantees the cache is always fresh. The cost: doubled write latency (cache + DB on every write). Works well when writes are infrequent relative to reads. DynamoDB DAX uses this pattern.
Write-back — speed at a risk
The cache absorbs writes and flushes to the DB in batches or after a delay. This is how CPU L1/L2 caches work, and it's how gaming leaderboards handle millions of score updates. The risk: cache node failure before flush = data loss. Mitigation: replicated cache (Redis Cluster), WAL in the cache layer, or accepting data loss for non-critical data.
Cache stampede prevention
Regardless of strategy, cache stampede (thundering herd on cold cache) is a real production concern. Solutions: lock-based population (only one thread fetches on miss), probabilistic early expiration (each read has a small chance of refreshing before TTL), or pre-warming critical keys on deploy.
Combining strategies
Production systems often combine: cache-aside for user profiles + write-back for view counters + write-through for session data. Name the combination in interviews to show you think about each data path independently.