April 17, 2026 - 10 min read - Caching Strategy

Your Cache Is Lying: Why "Just Add Redis" Eventually Breaks Everything

At some point every growing system slows down. Queries get heavier, traffic increases, and latency creeps up. So you add cache and everything gets fast again, for a while.

Then production gets strange. Users see outdated data, permissions do not refresh, inventory drifts, and state appears to revert for no reason. Nothing crashes, but consistency erodes.

Cache can improve speed while quietly reducing reliability.

The Problem: Cache Is Not a Source of Truth

Cache is not a faster database. It is a stale snapshot of reality that may be outdated, partially invalid, or flat-out wrong at any moment.

Where It Breaks in Real Systems

1. Write then stale read from cache

You update the database, but cache still holds the old value. The next read hits cache and users get stale data immediately after a successful write.

2. Race conditions during cache fill

Two requests miss cache, both fetch from DB, and both set cache. A slower response with older data can overwrite fresher data.

3. Partial invalidation

You update one key but forget dependent keys. Different parts of your system now disagree about the same entity.

4. TTL timing failures

Expiry can trigger thundering herds and DB spikes, or force inconsistent recomputation in the middle of critical flows.

5. Distributed cache desync

In multi-instance setups, one node updates while others serve old entries. You end up with multiple realities at once.

The Core Mistake

Teams treat cache as reliable state. It is only a best-effort optimization layer.

The Fix: Design Systems That Do Not Trust Cache

1. Keep critical logic off cache values

-- Bad
if cached_balance >= 1000 then
  allow_withdrawal()
end

-- Good
balance = fetch_from_db()
if balance >= 1000 then
  allow_withdrawal()
end

Cache is fine for display speed, not irreversible decisions.

2. Treat cache as a hint

Read cache first for performance, but verify with authoritative storage on critical paths.

3. Use write-invalidate or write-through

-- Invalidate
update_db()
delete_cache(key)

-- Write-through
update_db()
update_cache(key, new_value)

Never update the database and leave cache untouched.

4. Build for stale and missing entries

Your logic must tolerate old values, empty values, and duplicate recomputation without corrupting outcomes.

5. Keep dependencies simple

One key should have one responsibility. Over-coupled key graphs make invalidation impossible to reason about.

6. Use versioned keys

user:123:v5 -> data

Increment version on writes so stale entries naturally fall out without complex race-prone invalidation.

7. Protect against stampede

Use request coalescing, locks, and staggered TTLs to avoid many concurrent DB hits on expiry.

Pattern That Works in Production

Cache-aside with safe writes:

data = cache.get(key)
if not data then
  data = db.fetch(key)
  cache.set(key, data, ttl)
end

Writes always go to the database first, then cache is invalidated or updated. Critical decisions do not trust cache alone.

What Not To Do

• Do not trust cache for permissions and authorization decisions.
• Do not use cache as authority for money or irreversible state changes.
• Do not skip invalidation after writes.
• Do not assume TTL alone solves consistency.

The Mental Shift

Stop thinking: Cache makes things faster.

Start thinking: Cache makes correctness harder, so design for stale data.

The systems that survive are not the ones with perfect cache. They are the ones that remain correct when cache is wrong.