Skip the cache on writes
Write-around sends your writes straight to the database and leaves the cache alone. Your cache learns about data only when a read misses and fills it.
Count what that buys. Writes stay as fast as your database allows, and your cache holds only data that reads have proven hot. There is no dual-write failure to reason about either, because your application never writes two places.
Fit it to data written far more often than it is read back, or read on a different schedule than it is written. Log entries, audit records, chat history older than today, metadata for uploaded files.
See why write-through would hurt there. You would evict hot entries to store rows nobody may ever request, while letting reads pull them in on demand keeps your cache pointed at what people actually look at.
The weakness
Find the weakness in the window after updating an already-cached key. Your database has the new value, your cache still has the old one, and readers keep getting the stale entry until it expires.
Add the one thing plain write-around lacks, which is why it almost never ships alone: delete the key as part of the write. Write the database, invalidate the key, and the next read misses and fetches fresh.
Trio, write-around plus delete-on-write plus cache-aside reads, as the workhorse combination behind most production caches, including the one a very large social network published.
Respect the delete's own sharp edge, covered in the read strategies. Deletes race with fills already in flight, and a fill carrying an old database read can land after your delete.
Keep the expiry as your backstop, bounding how long such an accident survives. If your data cannot tolerate even that bounded window, take it as the signal you have outgrown write-around and should pay the write-through tax on those specific keys.
Worked example
Lena runs the messaging backend at a logistics startup. Drivers send about 900 messages per second, but a given conversation is typically read heavily for an hour and then almost never again. Early on, someone had configured write-through, so every message landed in Redis, and week-old conversations nobody would reopen were evicting the live ones; the hit rate for active conversations sat at a disappointing 71 percent. Lena switched writes to go straight to Postgres, with a DEL on the conversation's cache key, and let cache-aside rebuild a conversation only when someone opened it. Memory usage for the cache fell 60 percent, and the active-conversation hit rate climbed to 97 percent because the cache finally contained only conversations people were actually reading. Write latency was unchanged, since Postgres had always been the slow half anyway.