Write-Through vs Write-Back vs Write-Around Caching

Write-through, write-back, and write-around are three strategies for handling writes in a cache sitting in front of slower, persistent storage — and they answer the same question differently: when a write happens, does the cache get updated immediately, later, or not at all? The choice trades off write latency, data durability, and how often reads hit stale or missing data.

This decision shows up anywhere a fast layer sits in front of a slow one: an application cache like Redis in front of a database, a CPU’s L1/L2/L3 cache in front of main memory, or a CDN in front of an origin server. The underlying tradeoff is identical at every layer.

Write-through: update both, together

In write-through caching, every write goes to the cache and the backing store at the same time, as a single logical operation. The write isn’t considered complete until both are done.

• Consistency: strong. The cache is never ahead of the store — what’s in cache always matches what’s durably stored.
• Latency: every write pays the cost of the slow store, since the operation can’t return until the store confirms.
• Durability: excellent. A cache failure right after a write loses nothing, because the store already has the data.

Write-through is the safe default: reads are always fast and always correct, at the cost of writes being only as fast as the underlying store.

Write-back (write-behind): update cache now, store later

In write-back caching, a write updates the cache immediately and returns success right away. The write to the backing store is deferred — batched and flushed later, either on a timer or when the cache needs to evict that entry.

• Consistency: weaker. There’s a window where the cache holds data the backing store doesn’t have yet.
• Latency: excellent for writes — they only touch the fast cache layer.
• Durability risk: a cache failure before the deferred write flushes means real data loss. This is the central risk write-back accepts in exchange for write speed.

Because of that durability gap, write-back is typically paired with some form of persistence for the pending writes themselves — a write-ahead log, replication, or battery-backed cache memory — so an unflushed write survives a crash even though the backing store hasn’t seen it yet. This is the same durability guarantee write-ahead logging provides for a database’s own writes: record the intent to write durably before (or alongside) applying it, so a crash mid-write doesn’t silently lose data.

Write-around: skip the cache on writes entirely

In write-around caching, writes go directly to the backing store and bypass the cache completely. The cache only gets populated on a subsequent read — a read miss pulls the data from the store and caches it then.

• Consistency: simple, since the cache never diverges from the store on the write path — there’s nothing to diverge, because writes never touch it.
• Write latency: limited by the store, same as write-through, but without the extra step of also updating the cache.
• Read penalty: a real one. If data is written and then read again immediately, that first read is a cache miss and has to go to the store — write-around trades this off deliberately, betting that most written data isn’t read again right away.

Write-around fits workloads where writes vastly outnumber re-reads of the same data soon after — bulk imports, logging pipelines, or write-heavy data that’s rarely queried immediately after ingestion. It avoids polluting the cache with data that may never be read.

Comparing the three

	Write-through	Write-back	Write-around
Where the write lands first	Cache + store together	Cache only	Store only
Write latency	Slow (store-bound)	Fast	Slow (store-bound)
Data-loss risk on crash	Very low	Real, unless mitigated	Very low
Cache/store consistency	Always in sync	Temporarily diverges	Never diverges (cache untouched by writes)
Read-after-write cost	Fast (cache hit)	Fast (cache hit)	Slow (cache miss on first read)
Best for	Read-heavy, correctness-sensitive workloads	Write-heavy workloads that can tolerate some risk	Write-heavy workloads rarely re-read immediately

Choosing one

Default to write-through unless you have a specific reason not to — it’s the easiest to reason about and the hardest to get wrong. Reach for write-back when write throughput is a genuine bottleneck and you’ve built in a way to survive a crash before the deferred flush happens; this is common in high-write-volume systems where store latency would otherwise cap throughput directly. Reach for write-around when writes are bulk or rarely re-read soon after — logging, ingestion pipelines, archival data — so you’re not spending cache capacity, which is finite and best reserved for an LRU-managed working set of frequently accessed data, on entries nothing will read again for a while.

Many real systems mix strategies by data type rather than picking one globally: write-through for data that’s read immediately after being written, write-around for bulk or archival writes, and write-back reserved for the narrow set of paths where write latency is the dominant cost and the durability tradeoff has been explicitly accepted. That’s a more accurate description of most production caching layers than any single strategy applied uniformly, and it’s worth designing for from the start rather than retrofitting later. General caching fundamentals — eviction, TTLs, invalidation — are covered in what caching is; this decision sits specifically on the write path.

The takeaway

Write-through keeps the cache and store perfectly in sync at the cost of slower writes. Write-back makes writes fast by deferring the store update, accepting a real data-loss window unless it’s explicitly mitigated. Write-around skips the cache on writes entirely, trading a slower first read for a cache that’s never polluted with data nothing will read again soon. None of the three is universally correct — the right choice depends on whether your workload is read-heavy, write-heavy, or write-heavy-but-rarely-re-read, and many systems apply different strategies to different data rather than choosing just one.