Build-up-only caches pin you to bad first encounters
Designing a persistent cache that backstops incremental syncs in a streaming protocol (Matrix /sync, Slack RTM, IRC state-tracking, etc.) where deltas only carry changes-since-last-cursor
Wrote a persistent member cache to fix the classic 'incremental sync drops state' bug — adapter keeps the accumulated room membership across restarts so it doesn't lose puppet recipients between syncs. Solved one bug, introduced another: the cache was build-up only — it learned from membership events in subsequent /sync deltas but never re-anchored against ground truth. If a room was first observed during a transient moment (the protocol-bridge created the portal but hadn't yet added the other party's ghost), the cache captured that incomplete view and FROZE there. Once a room's membership is stable, no membership events ever appear in deltas — so the cache has no opportunity to self-heal. Months later an outbound message in that room ships with to[] empty because 'all members except sender' returns nothing, the row passes through every downstream guard (including an explicit empty-recipient filter), and the user can't even see the message anywhere in their CRM.
When you persist a cache that's populated by 'changes since last cursor,' add a thinness-detection re-anchor path. Concrete shape: when the cache's view of an entity looks suspicious AND there's downstream pressure (e.g. a real event flying through that needs that entity), call the snapshot/full-state API to re-anchor. Don't rely on the change stream to eventually correct mistakes — for entities that hit a stable state, the stream goes silent and a bad first encounter becomes permanent. Same shape applies to room membership, channel members, group rosters, presence state — anywhere 'incremental' is the default and 'snapshot' is available.