Cache Invalidation Strategies

Caching speeds up reads, but every cached value is a copy of data that lives somewhere else, and copies drift out of sync the moment the source changes. Invalidation is the discipline of deciding when a cached entry stops being trustworthy and what to do about it. Get it wrong and users see stale prices, outdated inventory counts, or old profile pictures; get it too aggressive and you erase the performance benefit of caching in the first place. There is no universally correct answer — the right strategy depends on how tolerant the application is of staleness, how often the underlying data changes, and how expensive a cache miss is.

The simplest strategy attaches an expiration timestamp to every cached entry. Once the TTL elapses, the entry is treated as absent and the next read repopulates it from the source of truth. TTLs require no coordination between the writer and the cache, which makes them trivially easy to implement and reason about, but they trade correctness for simplicity: for up to the length of the TTL, readers may see data that no longer matches the database. Systems commonly use short TTLs (seconds) for volatile data like stock prices and long TTLs (hours or days) for near-static data like a country list.

Write-through caching updates the cache synchronously as part of every write to the database, so the cache is never allowed to go stale in the first place — every write pays the extra latency of touching both stores. Write-behind (write-back) caching instead accepts the write into the cache immediately and asynchronously flushes it to the durable store later, which is fast but risks losing the update if the cache node crashes before the flush completes. Both patterns differ from TTL-based caching in that they proactively keep the cache correct rather than passively letting it expire.

A more precise approach deletes or updates the specific cache key the moment its underlying row changes, typically triggered from the application code or a database change-data-capture (CDC) stream. This minimizes the staleness window to essentially the propagation delay of the invalidation message, but it requires the write path to know every cache key that could be derived from the data it just changed — a non-trivial bookkeeping problem when the same row feeds multiple cached views (e.g. a user's profile cached both standalone and embedded inside a feed post).

In practice, teams blend approaches: TTLs act as a safety net that bounds worst-case staleness even if an explicit invalidation is missed, while explicit invalidation keeps the common case fast and fresh. The right mix depends on read/write ratio — read-heavy, write-rare data favors long TTLs with explicit invalidation on the rare write, while write-heavy data may not benefit from caching at all.