Caching with Intent

Most performance bugs are not caused by a missing cache but by a cache that outlives its truth. A cache is a bet that the data you have now will still be correct when you serve it later, and every bet needs an expiration condition. The trouble is that developers often add caching as a reflex—wrap a function in memoization, put a CDN in front of an API, throw Redis at a hot query—without naming what invalidates the entry. The result is a system that feels fast in the happy path and quietly serves stale, sometimes dangerous, data for minutes or hours. Caching with intent means starting from the invalidation rule, not the storage layer. Ask: what event makes this value wrong? Is it a write to the same row, a deploy, a clock tick, or a user action? If you cannot answer in one sentence, you are not ready to cache. The answer determines the mechanism: time-to-live, write-through, event-driven purge, or no cache at all. Getting this right is less about picking Redis versus Memcached and more about drawing a clear ownership line between the source of truth and its copies.

Consider a product page that shows price and inventory. The price changes rarely, but inventory changes with every purchase. If you cache the whole page for five minutes, you will oversell or show wrong availability. A better design caches the price separately with a long TTL and invalidates it on a pricing update event, while inventory is either fetched fresh or cached for a few seconds with a short TTL and a write-through path. This split forces you to model the data's volatility, not just its popularity. The same logic applies to user sessions versus user profiles, or to a list of trending articles versus the article bodies themselves. High-churn data and low-churn data should live in different caches with different rules. When you mix them, the most volatile piece dictates the TTL for everything, which wastes the cache's value and still risks staleness. The discipline is to tag each cached item with a volatility class and an invalidation trigger, then let those tags drive the implementation. That is the difference between a cache that helps and a cache that haunts you.

Once the invalidation rule is explicit, instrument it. A cache without metrics is a rumor. Track hit rate, miss rate, eviction rate, and, crucially, age at read—how old the data was when it was served. If your p99 age at read exceeds your business tolerance for staleness, the cache is not doing its job, even if the hit rate looks great. Also watch for thundering herds: when a popular key expires, a thousand requests can stampede the origin. The fix is not to extend the TTL blindly but to add request coalescing, stale-while-revalidate, or a short jitter to expiration times. In distributed systems, clock skew and network partitions can make invalidation messages arrive late or never, so design for eventual consistency and make the read path tolerant of slightly old data where possible. Finally, document the cache's contract: what it stores, how long, what invalidates it, and who owns it. A cache is not a magic layer; it is a piece of infrastructure with a lifecycle. Treat it with the same rigor as your database schema, and it will reward you with speed that does not lie.