In a cache-aside pattern, a service updates a row in its database and then deletes the corresponding key from the cache (instead of writing the new value directly into the cache). Why is 'invalidate on write' usually preferred over 'update the cache value on write', and what race condition can still leave the cache holding stale data afterward?

## Two ways to handle a write In cache-aside, reads and writes follow separate, independently-timed paths, and the pattern doesn't dictate a single correct way to handle writes — but the two realistic options are: | Strategy | What the write path does | |---|---| | **update-on-write** | after writing the new value to the database, also write that same new value into the cache | | **invalidate-on-write** | after writing to the database, delete the corresponding cache key rather than trying to write a new value into it | Under invalidate-on-write, the very next read for that key becomes an ordinary cache miss, which triggers the standard load-from-database-then-populate flow described by the base pattern, and the cache ends up holding a value that was read fresh from the database rather than one assembled by the write path. ## Why invalidating is preferred Invalidate-on-write is generally preferred because it avoids a whole class of correctness bugs that come from computing the cache's new value in two different places. If a write handler tries to construct the "new" cached value itself and push it into the cache, it has to reproduce whatever the database actually computed: - default column values - triggers - computed/generated columns - timestamps set by the DB engine - or partial-update semantics Any divergence between what the app thinks it wrote and what the database actually stored leaves the cache silently wrong. **Deleting the key sidesteps all of that:** the next reader is guaranteed to get whatever the database says the current value is, because it goes through the exact same read path as any other miss. It also collapses multiple back-to-back writes to the same key into one eventual reload instead of several redundant cache writes. ## The race that still leaves stale data The problem is that invalidate-on-write is not atomic with respect to concurrent reads, and the classic race goes like this: 1. **Thread A** issues a read for key K, misses the cache, and starts a query against the database — at this point it has read the pre-update value of K but has not yet written it back to the cache. 2. Concurrently, **Thread B** performs a write: it updates K in the database to a new value and then deletes K from the cache. 3. Because Thread A's database read already happened before Thread B's write committed, Thread A is holding the old value. 4. If Thread A's cache `SET` (writing that old value) executes after Thread B's `DELETE`, the cache ends up holding the stale pre-update value — and because nothing else will invalidate it, it stays wrong until its TTL expires naturally. ## Why it is so hard to catch This race requires a fairly specific interleaving (a concurrent slow reader racing a writer on the same hot key), so it's rare per-request but not rare in aggregate on high-throughput hot keys, and it's insidious because it doesn't fail loudly — the system just quietly serves stale data for up to a full TTL window, which can look like flaky bugs that are hard to reproduce because they depend on timing. It's more likely to bite when the database read in the miss path is slow (e.g., a complex query or replica lag) relative to the write path, widening the race window. ## Mitigations, and their ceiling Common mitigations include: - keeping **TTLs short** enough that staleness windows are bounded to something acceptable for the domain; - using a **"delayed double delete"** — deleting the cache key again a few hundred milliseconds after the write, to catch any stale value a racing reader wrote in between; - using **compare-and-set/versioned writes** so the cache `SET` only lands if the version it read is still current; - or, for read replicas, making sure the miss-path read is not served by a lagging replica relative to the write. None of these eliminate the race outright without adding real coordination (e.g. a distributed lock around the key), which is usually not worth the complexity for the rarity and bounded blast radius of the issue.