Caching and Invalidation

Start with the idea

A TTL trades staleness for simplicity, explicit invalidation trades simplicity for correctness, and write-through trades write latency for both. The failure modes are the interesting part: a stampede when a hot key expires, and unbounded growth without an eviction policy. Naming which staleness your product can tolerate is the real answer.

A cache is a second copy of data, so every design must answer when that copy is valid. A time-to-live is easy to operate but permits bounded staleness. Explicit invalidation can reduce staleness but must account for every writer and failure path. Write-through updates cache and source together from the application's point of view, but partial failure and ordering still need a policy. The right choice depends on whether a stale value is harmless, confusing, or financially dangerous.

Suppose a product page is read thousands of times but price changes rarely.