Stop 11 · CachingTopics · 5/8

Cache Invalidation Strategies

In short

Caching is easy. Knowing when a cached copy is wrong is the hard part. Get it wrong and users see yesterday's price, or a deleted post that refuses to go away.

Deciding when cached data becomes stale and needs to be refreshed or removed — TTL expiry, explicit invalidation on writes, or event-driven invalidation.

The blob character wipes a dish off a canteen chalkboard beside an empty pot.

Think of it like this

Wiping the canteen board

The canteen board says rajma chawal. When the pot runs out, someone must wipe it off, or students keep queuing for nothing. Some items get wiped at closing time anyway. Cache invalidation is deciding who wipes what, and when: on a timer, or the moment things change.

Watch it happen

A price update, invalidated everywhere

UPDATE price

DEL key

Publish

Servers

Next read

1/5An admin changes product 42's price. The database row is updated first.

The big ideas

What you need to know

TTL expiry

Let entries expire after a set time. Simple and safe, but data can be stale until then.

Delete on write

When data changes, delete its cache key. The next read fetches fresh data.

Event-driven

Publish a change event, through Redis pub/sub or a queue, so every cache layer clears its copy.

Version your keys

Put a version in keys, like products:v3:42. Bumping the version makes every old key unreachable at once.

See it in code

Walk through the code

1export async function updatePrice(id: number, price: number) {2  await db.products.update(id, { price });3 4  await redis.del(`product:${id}`);5  await redis.publish("invalidate", `product:${id}`);6}7 8// Every app instance listens and clears its local copy9const sub = redis.duplicate();10await sub.connect();11await sub.subscribe("invalidate", (key) => localCache.delete(key));

1/4Write to the database first. It's the source of truth.

In node-redis, a subscriber needs its own connection, hence duplicate(). localCache is an in-memory cache like lru-cache.

Save yourself the pain

Common mistakes

Oops

Deleting the cache key before writing to the database.

Do this instead

Another request can refill the cache with old data in between. Write the database first, then delete.

Oops

Relying on short TTLs alone for data like prices or stock.

Do this instead

Keep a TTL as a safety net, and also delete the key explicitly whenever that data changes.

Your mission

Break and fix stale data

~25 min

Quick check

Why delete the cache key on update instead of writing the new value into the cache?

Go deeper

1Implement explicit cache invalidation: clear a cache key whenever the underlying data updates.
2Compare TTL-based expiry vs explicit invalidation for a specific use case.
3Learn why 'cache invalidation is one of the two hard problems in computer science' is a real, not just a joke.