A cache is a copy. The database, object store, or upstream service remains the source of truth.

That copy is useful because it is fast. It is dangerous because it can become stale.

Cache invalidation is the work of removing, refreshing, or bypassing cached data when the source data changes. Perfect freshness is rarely the goal. What most systems aim for is bounded staleness: knowing how stale a cached value can be, and making sure that bound is acceptable for the feature.

In this chapter, we will cover what cache invalidation means, why it is difficult, the common strategies, the race conditions that show up between reads and writes, distributed invalidation for local and multi-region caches, and the production practices that keep caching safer.

Cache invalidation is the process of making sure the application does not keep serving an old cached value after the underlying 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: delete the cached value so the next read reloads it, update it with the fresh value, or expire it after a fixed time using TTL. Most production systems combine these. For example, they delete on write and also use TTL as a safety net.