Cache Write Policies
Three ways to handle a write when you have a cache in front of the store. Each policy is a different bet about durability, throughput, and how stale your data is allowed to get.
What is Cache Write Policies?
The 60-second primer
A cache write policy decides what happens when a write changes data that the cache holds in front of a slower store. A cache is fast; the backing store (memory, disk, database, an upstream API) is slow. Reads are easy — the cache answers if it has the value, otherwise it loads from below. Writes are where the design choices live.
Three questions decide the policy. Does the write update the cache? Does it update the backing store right now or later? And what happens on a write that misses the cache — do you allocate a cache line or skip it? The three classic answers — write-through, write-back, and write-around — make different tradeoffs across durability, latency, throughput, and the staleness window between the two layers.
These policies show up at every layer of the stack: in your CPU's L1/L2/L3 caches, in OS page caches, in database buffer pools, in distributed caches like Redis sitting in front of Postgres, and in CDNs caching objects from origin. The names are the same. The tradeoffs are the same. Pick the wrong one and you either lose data on a crash, blow up your write latency, or watch your cache hit rate flatline.
Why the policy choice matters
- Write latency — write-through forces every write to wait for the slow store; write-back lets writes finish at cache speed.
- Crash safety — write-back can lose every dirty line that hadn't been flushed yet; write-through never can.
- Cache pollution — writing data that won't be re-read for hours wastes a slot. Write-around fixes this by keeping write-only data out of the cache entirely.
- Write traffic to the backing store — write-back coalesces repeated writes to the same key into one flush; write-through hits the store on every single write.
Where these policies live in practice
Modern CPUs use write-back for the L1 data cache (with cache-coherence protocols to keep dirty lines safe across cores). Linux's page cache is write-back, with fsync() forcing a flush. Postgres's WAL is essentially write-through for durability. Redis cache-aside patterns in front of a SQL DB often use write-around for big infrequently-read blobs.
Side-by-side
How they compare
The same concepts, on the same axes. Use this as a map; the individual pages are the territory.
| Policy | Where writes go | Crash safety | Write latency | Best for |
|---|---|---|---|---|
01Write-through | Cache + store (both) | Safe — store is always current | Slow — bound by store | Durability-critical, read-heavy |
02Write-back | Cache only, flush on evict | Risky — dirty lines lost on crash | Fast — cache speed | Write-heavy, hot keys, CPU caches |
03Write-around | Store only, bypass cache | Safe — store is the only writer | Same as store write | Write-once, read-rarely workloads |
- Where writes go
- Cache + store (both)
- Crash safety
- Safe — store is always current
- Write latency
Slow — bound by store- Best for
- Durability-critical, read-heavy
- Where writes go
- Cache only, flush on evict
- Crash safety
- Risky — dirty lines lost on crash
- Write latency
Fast — cache speed- Best for
- Write-heavy, hot keys, CPU caches
- Where writes go
- Store only, bypass cache
- Crash safety
- Safe — store is the only writer
- Write latency
Same as store write- Best for
- Write-once, read-rarely workloads
Decision guide
Which one should you use?
A practical tour of when each algorithm wins.
Decision guide
- You can't afford to lose a single write (payments, audit logs, financial ledgers) → write-through. The store is always authoritative.
- The same key is written many times in quick succession (CPU registers spilling, an in-memory counter, a hot session value) → write-back. Coalescing identical writes is a huge win.
- Most writes never get read back (log ingestion, telemetry, archival uploads) → write-around. Don't pollute the cache with cold data.
- You're sitting in front of a remote, slow, or expensive backing store (S3, an upstream API, an OLAP warehouse) → write-back with periodic flush, if you can tolerate the durability gap.
- You need strong consistency between cache and store and have multiple readers → write-through, or pair write-back with a coherence protocol (MESI for CPUs, invalidations for distributed caches).
Write-allocate vs no-write-allocate is an orthogonal choice
On a write miss, you can either pull the line into the cache first (write-allocate, usually paired with write-back) or skip it (no-write-allocate, usually paired with write-through). Don't confuse this with write-around — write-around bypasses the cache on every write, hit or miss.
Concepts in this track
3 concepts, in order
Each links to a concept page with its own explanation, prototype, and quiz.
Write-Through
Every write goes to cache and the backing store in lockstep. Simple, safe, and slow.
Write-Back
Writes hit cache only; dirty lines flush to the store on eviction. Fast — and risky.
Write-Around
Writes skip the cache entirely. Keeps the cache clean for hot reads, costs you on re-reads.
Related tracks
If this one clicks, try these next.
Cache Eviction
When the cache fills up, something has to go — and which one you pick decides your hit rate. Ten classic policies, side-by-side.
Garbage Collection
How a runtime reclaims memory you stopped using — without you ever calling free(). Eight algorithms, from the counter on every object to the collectors that run alongside your program.
Memory Allocation
Before garbage collection ever runs, something has to hand out the memory. Six allocators — four ways to pick a hole, plus the two structured schemes real kernels actually ship.