Caching Strategies & Cache Invalidation

The most common pattern: the application checks the cache first, on a miss it reads from the database, then writes the result into the cache for next time. Reads are fast after the first miss, but the cache and database can drift out of sync if the underlying data changes without going through this same path.

Every write goes to the cache and the database together, synchronously, before the write is considered done. This keeps the cache always consistent with the database, at the cost of every write now paying the latency of two systems instead of one.

A write goes to the cache immediately and is considered done, then gets flushed to the database asynchronously later. This makes writes fast, but risks data loss if the cache fails before the flush happens, and needs careful design to avoid it.

The simplest invalidation strategy: every cached entry expires automatically after a set duration, forcing a fresh read from the source of truth. It doesn't require any explicit invalidation logic, but it means the cache can serve stale data for up to the full TTL window, and picking that window is itself a trade-off between staleness and load on the database.

The application actively deletes or updates a cache entry the moment the underlying data changes, e.g. a user edits their profile, and that write path also deletes the cached profile so the next read is forced to refetch. This gives tighter consistency than TTL alone but requires the application to correctly find and invalidate every cache entry that could be affected by a given write, which gets hard fast as relationships between cached data grow. The usual answer is to track, alongside the cache, which cached entries depend on which underlying thing, so changing that thing can invalidate all of them in one step instead of hoping every write path remembered.

Happens when a popular cached entry expires and a burst of concurrent requests all miss the cache at the same instant, all hammering the database simultaneously trying to refill it. Mitigations include locking so only one request refills while others wait, or staggering TTLs so not everything expires at the same second.

Decides what gets removed when the cache is full, not just when data goes stale. LRU (least recently used) is the most common default, evicting whatever hasn't been accessed in the longest time, on the assumption that recently used data is likely to be used again soon. When that assumption fails, counting how often an entry is used, with older activity fading over time, keeps genuinely popular data resident while letting a one-off scan pass through without flushing everything.

A cache can live in the browser (HTTP caching headers), at the CDN edge, in front of an application server (like Redis or Memcached), or even inside a single process's memory. Each layer trades how close it is against how much it can hold and how many different clients can share it.

Matters as much as how: caching data that's read far more often than it's written, and that can tolerate at least some staleness, gives the best return. Caching data that changes on nearly every read, or where staleness is unacceptable (like real-time account balances), often isn't worth the complexity a cache adds.

Requests that ask for something which never existed, like a probe for user ID -1 or a stream of invented identifiers. Every one misses the cache, reaches the database, finds nothing, and writes nothing back, so the next identical request repeats the whole trip. Unlike a stampede this can be driven deliberately, and the fix is counter-intuitive: cache the "not found" answer too, with a short expiry, so the second request stops at the cache.

Two shapes of the same problem. Breakdown is one popular key expiring and sending a focused burst at the database. Avalanche is thousands of unrelated keys, all written at the same moment by a restart or a nightly job, expiring within the same second and shifting their combined traffic at once. Locking fixes the first, because there is one key to queue behind. Only spreading expiry times apart fixes the second.

When one cache holds both disposable data and data that must survive, like sign-in sessions alongside cached query results, a blanket eviction policy will happily throw the sessions away to make room. The usual answer is to let eviction consider only entries that carry an expiry, and give an expiry only to the disposable ones, so anything without a deadline is never a candidate for removal.