Filled From The Follower

The write path commits to the primary and then deletes the cache key. Reads use cache-aside and fill from a read replica that trails the primary by about 200 ms. Users report that an edit shows up, then reverts to the old text and stays that way for the rest of the TTL. What is happening?

Two application instances keep inconsistent in-process copies of the row, and the user's requests are landing on different instances each time

A read that misses inside the lag window fills the cache from a replica that has not applied the write, so the old value is cached

The cache delete is issued before the commit is durable on the primary, so any reader that misses reloads a row the database has not written yet

The cache entry's TTL is being extended on every read, so the entry written at edit time never ages out of the cache tier