Performance
Write-through vs write-back cache: interview questions and practical design
Write-through caching updates the cache as part of a write path, while write-back caching acknowledges or buffers writes before the source of truth is updated.
Written and reviewed by Sahil Srivastav
What it actually is
Write-through caching updates the cache as part of a write path, while write-back caching acknowledges or buffers writes before the source of truth is updated.
The choice moves latency and risk between the request path and asynchronous flush. Write-back can improve throughput but makes durability, ordering, and loss recovery central design questions.
The useful interview answer is precise about the boundary: A write usually reaches the durable store and cache in a defined order. If cache update fails after commit, readers may see stale data; invalidate or rebuild rather than claiming atomicity.
Why it matters in production
The choice moves latency and risk between the request path and asynchronous flush. Write-back can improve throughput but makes durability, ordering, and loss recovery central design questions.
Write-through still needs failure handling: a cache success is not automatically a durable database commit unless the cache is the intended source of truth.
How it works
Write-through ordering
A write usually reaches the durable store and cache in a defined order. If cache update fails after commit, readers may see stale data; invalidate or rebuild rather than claiming atomicity.
Write-back buffer
The cache records dirty state and flushes later. It needs a durable queue or log, retry and ordering rules, backpressure, and a clear answer for process or node loss.
Read consistency
Readers must know whether they read the cache, source, or a session-owned write. A write-back design often needs versioning and reconciliation to prevent older flushes overwriting newer values.
Implementing it
Draw the write and failure timeline for both policies.
Define the durability point and recovery process after a cache node disappears.
Test two writes to one key with reordering and a failed flush.
Interview questions and how to answer them
When is write-back appropriate?
When throughput or latency benefits justify asynchronous durability and the data can tolerate or recover from loss. It is risky for state whose acknowledgement must mean durable commit.
What if the cache and database disagree?
Use versions, a source-of-truth decision, reconciliation, and a repair policy. Never resolve by blindly copying whichever was read first.
Is write-through atomic?
Only within the component that owns the write. Across a cache and database, failures can still split the effects unless a stronger shared protocol exists.
Answers that lose the round
- Calling a volatile cache a durable write-back store.
- Ignoring dirty data on eviction or node loss.
- Letting an old asynchronous flush overwrite a newer value.
- Choosing write-back for money or inventory without a loss and reconciliation plan.
FAQ
Which is easier to reason about?
Write-through generally has simpler durability semantics; write-back can be faster but adds a queue, recovery, and ordering system.
Can write-back use Redis?
It can, but durability settings and replication must match the loss tolerance, and a separate durable log may still be required.
How do I answer in an interview?
State the durability and freshness requirement first, then compare latency, failure, ordering, and recovery rather than choosing by slogan.