Caching Strategies & Invalidation — Cheatsheet

Read/write patterns

Cache-aside (lazy)	App checks cache, loads from DB on miss, then populates.Most common; cache can go stale until TTL.
Read-through	Cache library loads from DB on miss transparently.
Write-through	Write hits cache and DB synchronously.Consistent, slower writes.
Write-back (write-behind)	Write to cache, flush to DB async.Fast writes; risk of loss on crash.
Write-around	Write straight to DB, skip cache.Avoids caching write-once data.

LRU	Evict least-recently-used.Good default for temporal locality.
LFU	Evict least-frequently-used.Better for stable hot sets.
TTL	Expire after a fixed time.Simple staleness bound.
FIFO / random	Cheap, ignores access pattern.

Stale reads	Cache diverges from source.Bound with TTL, or invalidate on write.
Thundering herd / stampede	A hot key expires and every request hits the DB at once.Fix: request coalescing, jittered TTLs, probabilistic early refresh.
Hot keys	One key gets disproportionate traffic.Fix: local (L1) cache, key replication.
Cold start	Empty cache after deploy/restart floods the DB.Fix: warm-up, gradual ramp.

“There are only two hard things: cache invalidation and naming things.” Name your invalidation strategy explicitly — TTL, write-through, or versioned keys — before the interviewer asks.
Pick the write pattern from the workload: write-through for correctness-sensitive data, write-back only when you can tolerate loss for throughput.
The thundering herd is the classic follow-up. Have coalescing or jittered TTL ready before you’re asked what happens when the hot key expires.