Caching Strategies
You'll learn to
- -Compare cache-aside, write-through, and write-behind
Knowing a cache pays off is one thing; the actual complexity is in how you populate it and keep it correct. The pattern you choose determines what happens on both reads and writes.
Cache-aside: the application checks the cache first, and only falls through to the database on a miss.
Store computed or fetched results in a fast store (usually Redis) to avoid repeating expensive work. The patterns for populating and invalidating caches are where the complexity lives.
You run a restaurant. Instead of cooking every dish from scratch, you pre-cook the most popular dishes at 11am before lunch rush (Cache-Aside pre-warm). When someone orders, you check your ready-made shelf first. If it's there, serve immediately. If not, cook it - and put a fresh copy on the shelf.
Cache-Aside (Lazy Loading): The most common pattern. Application checks cache first. On miss, app fetches from DB, stores in cache, returns result. The cache is only populated on misses - "lazy" means you only cache what's actually requested. Simple to implement. Risk: cache stampede on cold starts.
Write-Through: Every write to the database simultaneously writes to the cache. Cache is always warm and consistent with the DB. But every write now takes twice as long (must update both DB and cache). Also wastes cache space for data that may never be read.
Write-Behind (Write-Back): Writes go to the cache first and return immediately. A background worker asynchronously flushes to the database. Ultra-low write latency. Risk: data loss if the cache crashes before flush. Used for analytics counters, batch operations.
Read-Through: The cache sits transparently in front of the database. Application reads from cache; if miss, the cache itself fetches from DB and stores it. Simplifies application code. The caching layer (not the app) manages misses.
Cache Invalidation is infamously hard. Two strategies: TTL (expire after N seconds - simple but potentially stale) and Event-Driven invalidation (publish a cache-busting event when the DB record changes - complex but accurate). Phil Karlton's famous quote: "There are only two hard things in Computer Science: cache invalidation and naming things."
- -Cache Hit Ratio = hits / (hits + misses). Target > 90% for meaningful impact.
- -TTL too short = too many DB hits. TTL too long = serving stale data.
- -Never cache data that changes every request or is user-specific-sensitive (PII).
- -Cache eviction policies: LRU (Least Recently Used), LFU (Least Frequently Used), TTL.
- -Warm the cache on startup for critical paths to avoid cold-start stampedes.
Why not just write to the cache and the database at the same time on every write (write-through), everywhere?
"That sounds safer since the cache is never stale."
"It keeps the cache consistent, but it means every write now pays the latency of two systems instead of one, and a write that succeeds in the database but fails in the cache leaves you in an inconsistent state you have to handle. Cache-aside is more common precisely because it keeps the write path simple: the cache is only ever a derived, disposable copy, never the thing a write depends on succeeding."