Redis Caching Patterns That Don't Turn Into Invalidation Nightmares

'There are only two hard things in computer science: cache invalidation and naming things' earns its status as the most-quoted line in engineering because every team relearns it the same way — by shipping a cache that serves stale data to a customer who noticed before anyone on the team did.

• Every cache key gets a documented TTL and an owner — 'we cache it' is not a strategy.
• Prefer cache-aside with explicit invalidation on write over time-based expiry alone for anything user-facing.
• Namespace keys by version so a schema change can invalidate an entire category atomically.
• Cache the expensive computation, not the entire response — it's easier to reason about invalidation at that granularity.

The invalidation nightmares I've debugged were never caused by Redis itself — they were caused by a cache added under deadline pressure with no plan for what happens when the underlying data changes. Redis is fast. The plan is the hard part.

A cache without an invalidation story isn't a performance optimization. It's a bug waiting for the right update.