Write-Through, Write-Behind, and Write-Around
Cache write policies decide when writes reach the origin: write-through synchronously, write-behind asynchronously with queueing risk, write-around bypassing the cache for writes.
Definition
Write-through updates cache and origin together synchronously — consistent at write cost. Write-behind (write-back) updates the cache immediately and flushes to the origin asynchronously, accepting a loss window if the flush fails. Write-around writes only to the origin and lets reads repopulate, avoiding cache pollution by write-once data.
Context and scope
Chosen per workload on Redis-backed stores, CDNs with purge APIs, and ORM second-level caches. The trade-off is write latency versus durability and staleness windows.
Common misconceptions
- Write-through guarantees consistency — it guarantees cache-origin agreement at completion; concurrent readers may still see interleavings
- Write-behind just batches writes — queued writes imply failure modes: retry, dead-letter, and rebuild-after-crash procedures must exist
- Write-around is a mistake — it is the right policy for write-once, read-rarely data that would otherwise evict useful entries
Anti-patterns
- Write-behind without durable queues, losing writes on cache node failure
- Write-through for high-frequency small updates and paying double latency per write
- Invalidating on write but never repopulating, converting every write-then-read into a miss storm
Related concepts
Related examples
Authoritative source
What it is
A cache needs a story for writes. Three canonical policies: synchronous dual write (through), asynchronous deferred write (behind), and origin-only write (around). Each picks a different point among write latency, durability, and cache freshness.
How it works
Write-through completes when both stores accept the update; failure rolls back visibly. Write-behind marks entries dirty, queues the flush, and completes early — crash recovery replays or loses the queue unless it is journaled. Write-around sends writes straight to origin; the cache entry expires or invalidates, and only re-reads repopulate it.
When to choose
Write-through for low write rates where coherence matters. Write-behind for bursty write workloads that absorb well in batches, only with durable queues and replay tooling. Write-around for bulk imports and archival writes that should not evict live data.
Pitfalls
Write-behind turns the cache into a system of record until flush — size that responsibility. Write-through with partial failure needs rollback ordering between stores. Write-around plus immediate reads produces miss storms; combine with warming or read-through on first access.