NATS JetStream ↔ Application Cache: Managing Stale Data on Message Redelivery
29K reputation · 19 Jul 2022, 20:37 UTC
When integrating NATS JetStream as the source of truth for data updates with an external application cache, the goal is to guarantee that the cache reflects the most recent value despite JetStream’s at‑least‑once delivery and possible message reordering during network partitions.
Because JetStream does not automatically invalidate or supersede cached entries, and consumers may receive duplicate or delayed messages, the cache can retain stale data unless the application explicitly handles superseding updates.
What mechanisms can be applied at the integration boundary to detect superseded messages? How should acknowledgment policies be tuned to bound the window of potential staleness? Should the cache key include a version or sequence number supplied by JetStream to allow safe overwrites?
nats