# Local and distributed cache coherence: stale data caused by missed invalidation messages

DevFeed: [Local and distributed cache coherence: stale data caused by missed invalidation messages](<https://devfeed.tech/articles/local-cache-plus-distributed-cache-the-coherence-bill-nobody-budgets-for-39606.md>)

Original publisher: [Read original article](<https://ankit-rana.com/logs/54-local-and-distributed-cache-coherence/>)

Author: hello@ankit-rana.com

Published: 2026-09-17T00:00:00Z

Content type: opinion

Language: en

Sources: [Ankit Rana | Mechanical Sympathy](<https://devfeed.tech/sources/ankit-rana-mechanical-sympathy.md>)

Topics: [Caching](<https://devfeed.tech/topics/caching.md>), [Redis](<https://devfeed.tech/topics/redis.md>), [data](<https://devfeed.tech/topics/data.md>), [Network](<https://devfeed.tech/topics/network.md>)

Tags: [cache](<https://devfeed.tech/tags/cache.md>), [cache-coherence](<https://devfeed.tech/tags/cache-coherence.md>), [caching](<https://devfeed.tech/tags/caching.md>), [consistency](<https://devfeed.tech/tags/consistency.md>), [data](<https://devfeed.tech/tags/data.md>), [distributed-cache](<https://devfeed.tech/tags/distributed-cache.md>), [distributed-systems](<https://devfeed.tech/tags/distributed-systems.md>), [jvm](<https://devfeed.tech/tags/jvm.md>), [network](<https://devfeed.tech/tags/network.md>), [redis](<https://devfeed.tech/tags/redis.md>), [ttl](<https://devfeed.tech/tags/ttl.md>)

## AI overview

The article explains that adding an in-process cache in front of a distributed cache can improve latency but creates independently stale copies across service instances. It focuses on Redis pub/sub invalidation, which provides no persistence, acknowledgement, retry, or replay, allowing instances to miss invalidation messages and serve stale data until their TTL expires.

## Source excerpt

An in-process cache in front of a distributed cache removes a network hop and adds one independent copy of the data per instance, each of which can be stale on its own schedule. Invalidation is normally broadcast over pub/sub, which is fire and forget, so any instance that is restarting, garbage collecting or briefly disconnected simply misses the message and serves stale data until its TTL expires. That TTL is not a performance setting, it is the maximum duration of incorrectness.