A cached value is only a copy. The database, object store, or another service still holds the real data. Engineers often call that real data store the source of truth.

The cache is useful because it is fast, but it can become dangerous when it gets out of date.

Cache invalidation means removing, refreshing, or skipping cached data when the real data changes.

Perfect freshness is rarely the goal for every cached value. Most systems aim for a clear freshness limit: they decide how old a cached value is allowed to be, and make sure that limit is acceptable for the feature. This is often called bounded staleness.

A stale price on a product page is annoying. A stale account balance in a payment flow can be dangerous. Those two cases should not use the same cache rules.

This chapter covers what cache invalidation means, why it is hard, common invalidation strategies, race conditions between reads and writes, invalidation across many caches, and the production habits that make caching safer.

Cache invalidation is the process of making sure the application does not keep serving an old cached value after the real data has changed.

When the database changes from 100 to 200, the cached value 100 is no longer correct. There are three basic things you can do:

Most production systems combine these. For example, they delete cached data when writes happen and also use TTL as a safety net.