Cache Invalidation
Practice this topic in a realistic system design interview
Caching improves performance by keeping frequently accessed data in a faster storage layer. But there is a problem. The original data can change while the cached copy stays the same. When that happens, the cache becomes stale.
A cached value is only a copy. The database, object store, or another service still holds the real data. Engineers call that real data store the source of truth.
Cache invalidation is the process of removing or updating stale cached data so users do not keep receiving outdated results.
Perfect freshness is rarely the goal for every cached value. Most systems 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.
This chapter covers why cache invalidation is difficult, the most common invalidation strategies, the races and failures that break them, and how to choose the right approach for a system.
1. Why Cache Invalidation Is Necessary
Suppose we cache the details of product 123. The database says the price is $100, and that value is stored in the cache.
Later, the product price changes to $90. The database now contains the new price, but the cache still contains $100.
If the application continues reading from the cache, users will see the wrong value.
This is the core cache invalidation problem. We now have multiple copies of the same data, and when the source changes, we need some way to make sure the cached copy does not remain stale forever.
There are three basic things you can do with a cached value once the source changes:
- Expire it after a fixed time, using a TTL.
- Delete it, so the next read reloads it.
- Update it with the new value.
The challenge is deciding when and how that cached value should be removed or refreshed. Most production systems combine these, for example deleting on write and keeping a TTL as a safety net.