Delete Not Overwrite

A cache-aside service currently writes the new value into the cache immediately after committing it to the database. Under concurrent updates to the same row, why do most teams delete the key instead of setting the new value?

A

A delete is applied atomically across every node of the cache cluster, while a set only lands on the single node that owns the key

B

Two writers can commit in one order and reach the cache in the opposite order, leaving the older value cached until something else clears it

C

Setting a value costs more than deleting one, so the write path ends up holding its database transaction open measurably longer under load here

D

Deleting the key frees memory in the cache tier, and that saving outweighs the extra database read the next request has to pay for