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 Stampede (Thundering Herd): When a high-traffic cache key expires, thousands of requests simultaneously go to the database, overwhelming it. Solutions: lock and re-populate (distributed mutex with Redis SETNX), probabilistic early expiration (randomly refresh before TTL), or background refresh with stale-while-revalidate.