When does caching make it worse?

Caching is the only performance technique that changes what your system says, not just how fast it says it. That property is priced into none of the design reviews where "add a cache" appears as a one-line remedy. A cache is a bet that the past predicts the present; here are the four ways the house wins.

Where does the bet go wrong?

Staleness with consequences. Some data forgives (a product description an hour old harms no one). Some does not (an entitlement check, a price, an inventory count). The failure is rarely the TTL chosen; it is that nobody wrote down which class the data belonged to, so the cache made the decision by default. Our first question in any caching review is not "what is the hit rate" but "who signed off on serving this stale, and for how long."

The stampede. A popular key expires, and every waiting request becomes an origin request at the same instant; the cache that absorbed 95% of load delivers 100% of it in one heartbeat, precisely when the origin is least prepared. Mitigations are well known (jittered TTLs, request coalescing, serve-stale-while- revalidate) and mostly unimplemented, because the stampede only happens on the day it matters.

The availability inversion. Once a cache absorbs most traffic, the origin quietly shrinks to fit the trickle, and the cache stops being an optimization and becomes load-bearing: its loss is now an outage, not a slowdown. The system's real capacity became the cache's capacity, and nobody re-derived the load path to notice. If flushing the cache at peak would take you down, you do not have a cache. You have a primary datastore with amnesia.

And the debugging tax, paid in perpetuity: every incident acquires a new first question ("is it cached?"), every bug report forks into hit-path and miss-path, and correctness issues develop the maddening property of disappearing when observed.

What would have to be true for the cache to pay?

The honest checklist is short. The data tolerates a stated staleness, signed by someone who owns the consequence. The hit rate is projected from measured access patterns, not hoped (a long-tail access distribution caches beautifully; a uniform one barely at all). The origin retains capacity to survive a cold cache at peak, or a warming plan exists in the runbook. And invalidation, the famously hard problem, has an owner per dataset rather than a shrug.

What do we recommend instead, first?

The boring alternatives that change no semantics: the missing index, the N+1 fixed at the source, the connection pool sized to arithmetic, the query that should be a materialized view. Half the caches we review exist to compensate for one of these, at the cost of a permanent correctness mortgage. Pay the principal, not the interest. Cache what is genuinely expensive and genuinely tolerant, and let the rest stay slow enough to be true.