Cache Invalidation

"There are only two hard things in computer science: cache invalidation and naming things." — Phil Karlton

I used to laugh at this quote. Then I spent a week debugging why our users were seeing prices from 3 hours ago. I stopped laughing.

Here's what nobody tells you about caching: the moment you add one, you stop having one source of truth. You now have two—your database and your cache. And keeping them in sync? That's the real job.

Why is it so genuinely hard?

It's not a single problem. It's a cluster of problems wearing a trench coat.

Data changes in unpredictable ways. A user updates their profile. An inventory item sells out. A price gets revised. Your cache doesn't know any of this happened — it just happily keeps serving the old value, convinced it's being helpful.

Then there's timing. Even when you do invalidate the cache, there's a window — however small — where stale data leaks through. In distributed systems with dozens of nodes, that window multiplies.

And then the classic trap hits: you delete a cache entry right as another process is reading it, a third process is writing to the DB, and a fourth is about to repopulate the cache with the old value. Welcome to race conditions.

The strategies engineers actually use:

→ TTL (Time-to-Live): Set an expiry. Simple, predictable. But you're accepting "stale for up to X minutes" as a business decision, not just a tech one.

→ Write-through: Update cache and DB together on every write. Consistent, but adds latency to your writes.

→ Write-behind (write-back): Update cache first, sync to DB asynchronously. Fast writes are risky—if the cache dies before the sync, you lose data.

→ Event-driven invalidation: Publish a change event whenever data updates; subscribers invalidate the relevant cache keys. Elegant at scale, complex to implement correctly.

The lesson I keep coming back to:

Caching is never just a performance decision. It's a consistency decision. Every cache entry is a bet that the data won't change before the TTL expires — or that you'll catch it when it does.

The engineers who get burned by cache bugs aren't the ones who don't understand caching. They're the ones who underestimated how many moving parts stand between "data changed in the DB" and "cache reflects that change."

Phil Karlton said it in the 90s. Thirty years of distributed systems later, it's still true.

If you're building anything at scale, treat cache invalidation with the same seriousness you'd give schema migrations or API versioning. It deserves it.