When your application updates a record that is also cached in Redis, do you delete the cached entry or overwrite it with the new value — and in which order relative to the database write?

## The two options on the write path *Cache-aside* (lazy loading) means the application, not Redis, owns cache population: a read looks in Redis, and on a miss loads from the database and stores the result. When a record then changes, you must decide what the write path does to the cached copy. There are exactly two options: - **Update in place** — recompute the cached representation and write it over the old one. - **Invalidate** — remove the cached key and let the next reader repopulate it through the ordinary miss path. Almost always, invalidate. ## Why invalidation wins under concurrency This is the decisive argument. Suppose writer A sets `price=10` and writer B sets `price=20` at nearly the same moment, and each pushes its own value into the cache after committing. The database serializes the two transactions and produces one true final row — say B's. But the two cache writes are separate, unsynchronized operations over a different connection with different latency. Nothing forces them into the same order as the commits. A's `SET` can easily land *after* B's, leaving Redis holding `price=10` while the database holds `price=20`. That divergence is not self-healing: it persists for the full remaining TTL, and every reader in that window gets a confidently wrong answer. Now replace both cache writes with deletes. Deletes are **idempotent** and **order-insensitive**: whichever of them executes last, the outcome is identical — the key is gone. The next reader misses, loads from the database, and caches whatever the database actually settled on. The race still happens; it just no longer has a wrong outcome. That is the general shape of the rule: prefer operations whose interleavings all converge to the same state. "Absent" is such a state; "holding one of several candidate values" is not. ## The other two reasons **Cost.** The cached entry is frequently not the raw row — it is a join, an aggregate, a rendered projection, serialized into some payload format. Updating in place means paying that entire read-path cost on every write, including for entries that will never be read again. Invalidation defers the cost to the moment someone actually asks, which is the whole point of a lazily-populated cache. **Duplication.** A write path that reconstructs every cached projection of a record has copied the read path's logic into a second place. The two drift: someone changes the read query, forgets the writer, and the cache begins serving a subtly different shape than the loader would produce. ## The price you pay Invalidation guarantees a miss on the next read of that record — a database round trip that an in-place update would have avoided. On a hot key updated frequently, that means repeated reloads. This is a good trade: **one predictable extra miss instead of a silent wrong value.** A miss is visible in your hit-rate metric and self-correcting; a stale cache entry is neither. (If a single very hot key produces a stampede of simultaneous reloads after invalidation, that is a separate concern with its own guards, such as a short-lived lock so only one loader hits the database.) ## Ordering: commit first, then invalidate Invalidating *before* the database write opens a wide, easily-hit hole: 1. Writer removes the cached key. 2. Writer's transaction is still running (or hasn't started). 3. A reader misses, loads the **old** row, and caches it with a **fresh full TTL**. 4. Writer commits. The cache is now stale, and the invalidation that was supposed to fix it has already happened. Nothing corrects it until expiry — potentially minutes or hours after the write. Worse, the window is as long as the write transaction itself, which is exactly when concurrent readers are most likely to arrive. Commit-then-invalidate has a much smaller hole: only a reader that *already* fetched the pre-commit row and is slow to write it back can lose the race with the delete. That window is one reader's database round trip, not one writer's transaction, and it requires unlucky interleaving. A separate question in this area covers detecting and guarding that residual stale-write-back race. ## Commit boundaries and failures Invalidate **after the transaction commits**, never inside it. Deleting inside an open transaction lets a reader repopulate from the pre-commit state, and if the transaction rolls back you have thrown away a perfectly valid entry for nothing. If the invalidation itself fails — Redis unreachable, connection reset — the entry stays stale. This is precisely why every cache-aside entry should carry a TTL: it bounds the blast radius of a lost invalidation to the remaining lifetime rather than forever. Log and count failed invalidations; a rising rate is a correctness signal, not background noise. ## Which removal command Both `DEL` and `UNLINK` remove the key; prefer `UNLINK` for large aggregates and as a default habit — the lazy-free question in this area explains the mechanism. ## The narrow case for updating in place Write-through caches (where the cache sits in front of the store and takes the write itself) and single-writer-per-key designs can legitimately write the value. If you can genuinely guarantee one writer per key, or you're storing a counter you mutate with an atomic Redis operation rather than overwriting, the concurrency argument dissolves. Say so explicitly when you claim the exception.