Caching Strategies

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.

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.