Cross-Node Cache Invalidation
Cross-node invalidation propagates cache clears through pub-sub or event streams so every instance drops stale entries — at the cost of races, at-least-once delivery, and tombstone bookkeeping.
Definition
In a fleet of application caches, a write on node A must invalidate entries on nodes B through N. Broadcast invalidation publishes a key or namespace event that all subscribers apply, pruning local entries. Delivery is at-least-once with retries; ordering races with writes; and versioned tombstones prevent older invalidations from being ignored.
Context and scope
Implemented over Redis pub-sub, Kafka topics, or database WAL tails. Alternative: short TTLs accepting staleness windows instead of coordination.
Common misconceptions
- Pub-sub invalidation guarantees consistency — it guarantees eventual clearing; a read between write and delivery still serves stale
- Once invalidated everywhere, the data is fresh — repopulation races: a slower reader can refill the stale value after the invalidation
- Broadcasting beats TTLs always — coordination cost, delivery failures, and debugging complexity often make short TTLs the cheaper choice
Anti-patterns
- Invalidating without versions, letting delayed messages be ignored as already-applied
- Filling caches with long-running queries that race invalidations and reinsert stale values
- Fire-and-forget publishes without delivery monitoring, silently leaving some nodes stale for hours
Related concepts
Related examples
Authoritative source
https://redis.io/docs/latest/develop/use/client-side-caching/
What it is
Local caches make each node fast and the fleet inconsistent. The moment one node writes, every other node holds an outdated truth. Broadcast invalidation is the coordination that prunes those truths fleet-wide.
How it works
The writer publishes an invalidation event — key, namespace, version — on a bus every node subscribes to. Handlers delete matching entries and record the version to reject replays and late deliveries. Redis client-side caching formalizes the same flow with server-tracked key invalidations.
When to use it
Strong freshness requirements across a fleet without centralizing the cache. Version every invalidation, monitor subscriber lag, and bound staleness with a TTL backstop in case delivery fails.
Pitfalls
The read-refill race is the classic bug: a query that started before the write completes after the invalidation and reinserts the old value — guard with versioned writes or read-through serialization. At-least-once delivery requires idempotent handling. Debugging requires per-node invalidation lag metrics.