Cache Invalidation Is Still the Hard Part

Cache-aside, where the application checks the cache first and populates it on a miss, works well for read-heavy data that changes infrequently. Write-through, updating the cache at the same time as the source of truth, fits data where staleness is unacceptable even briefly.

Picking the wrong pattern for the data's actual change frequency is the root of most caching bugs. A write-heavy resource cached with a naive cache-aside pattern and no active invalidation will serve stale data constantly, no matter how well the cache itself performs.

A default five-minute TTL applied everywhere because it seemed reasonable is rarely actually reasonable for every piece of data in your system. A user's session data might tolerate a few seconds of staleness; a product catalog might tolerate an hour; an account balance might tolerate none at all without active invalidation.

Set TTLs per data type based on how long stale data is actually acceptable for that specific use case, not a single value copied across every cached resource because it's easier to configure once.

TTL-based expiry alone means data can be wrong for up to the full TTL window after it changes, which is fine for some data and unacceptable for other data in the same system. For anything in the second category, invalidate the cache entry explicitly, as part of the same operation that changes the underlying data, rather than waiting for it to expire naturally.

This needs to be reliable: a write path that sometimes forgets to invalidate the cache, because someone added a new way to update the data without updating the invalidation logic, is a recurring source of stale-data bugs that are hard to reproduce after the fact.

Say a product's price gets updated in the source database, and the cache entry for that product's page, with a fifteen-minute TTL, keeps serving the old price for up to fifteen minutes after the change. A customer checks out during that window at the stale price, and now there's a pricing discrepancy to resolve after the fact.

Adding explicit cache invalidation to the price-update code path, clearing the specific cache key the moment the price changes, removes the staleness window entirely for this specific case, while leaving the TTL as a safety net for cases the explicit invalidation might miss.

• One TTL value applied uniformly across data with very different staleness tolerance
• Write paths that update the source of truth without invalidating the corresponding cache entry
• No monitoring on cache hit rate, so a cache that's stopped being effective goes unnoticed
• Caching layered on top of a service without anyone owning invalidation correctness for new features

A cache that's working shows up in latency graphs as an improvement, but that alone doesn't tell you whether it's serving correct data. Track hit rate to catch a cache that's stopped being effective, and track stale-data incidents specifically, tagged as such, to catch invalidation bugs before they become a pattern.

A cache with a great hit rate and no visibility into staleness incidents can still be quietly serving wrong data most of the time. The two metrics answer different questions, and you need both to trust the cache is actually helping.

It's easy to only think about caching successful lookups and forget that a repeated failed lookup, a not-found or a permission check that returns no, hits your backend just as hard as a successful one would. Caching negative results, with a shorter TTL than positive ones, protects against a specific pattern: a client repeatedly checking for something that doesn't exist yet.

This matters most for lookups triggered by client-side polling or retries, where a missing resource being checked for repeatedly can generate meaningful load if every check bypasses the cache. A short negative-result TTL absorbs that pattern without risking long-lived incorrect data if the resource does show up shortly after.