Caching
Write-Through vs Write-Back
Where a write lands first decides a hard tradeoff: write-through keeps the cache and database in lockstep at the cost of write latency; write-back is fast but can lose data if the cache fails before flushing.
- Write-through: a write updates the cache and the database synchronously, in the same operation — cache and source of truth never diverge, but write latency includes the database round trip
- Write-back (write-behind): a write updates only the cache, with the database updated asynchronously later — very low write latency, but a cache node failure before the async flush completes loses that write permanently
- Write-around: a write goes directly to the database, bypassing the cache entirely — avoids filling the cache with data that is written once and rarely read
- Write-through effectively prevents staleness by construction, which is a more reliable answer to cache invalidation than invalidating after the fact
- The right choice is a durability decision: write-back is fine for data where losing the last few seconds is tolerable (view counters, ephemeral state), never for anything that must survive a crash (financial transactions)
| Strategy | Write latency | Durability risk | Good fit |
|---|---|---|---|
| Write-through | Higher (waits on DB) | None | Data that must never be lost or stale |
| Write-back | Lowest | Loses unflushed writes on cache failure | High-write-volume, loss-tolerant data |
| Write-around | DB-bound, cache untouched | None (no cache involved) | Write-once, rarely-read data |