There's an old joke that there are only two hard problems in computer science: cache invalidation and naming things. The joke endures because it's true. Caching is easy to add and hard to keep correct, and nearly every caching bug is really an invalidation bug: the cache is serving data that no longer matches the database. This article covers the strategies for keeping cached data correct, from the simple TTL to explicit and event-driven invalidation, and how to reason about which to use.
This is part 13 of the Redis Masterclass, following refresh-ahead.
Why invalidation is hard
The difficulty is that the cache and the database are two copies of the same data, and the moment the database changes, the cache is wrong until something fixes it. Every strategy is a different answer to "how does the cache find out the underlying data changed," and each trades freshness, complexity, and correctness differently. There's no perfect answer, which is the real content of the joke: you're always choosing a tradeoff.
Strategy 1: TTL expiration
