Write-Through vs Write-Back Cache: What is the Difference?
Compare write-through and write-back caching: how each handles writes, latency, and the data-loss risk trade-off.
Expected Interview Answer
A write-through cache writes to the cache and the underlying database synchronously as one operation before confirming success, while a write-back (write-behind) cache writes only to the cache immediately and flushes to the database asynchronously later.
In write-through, every write blocks until both the cache and the database confirm the update, so the cache and database are always consistent and a crash never loses data, at the cost of higher write latency since two systems must be updated per write. In write-back, the write completes as soon as the cache accepts it, and the database is updated later in batches, giving much lower write latency and fewer database writes overall, but at the risk that a cache failure before the flush can lose data that was never persisted. Choosing between them is a direct trade-off between write latency/throughput and durability guarantees.
- Write-through: cache and database always consistent
- Write-through: no data loss risk on cache failure
- Write-back: much lower write latency for the caller
- Write-back: batches writes, reducing database load
AI Mentor Explanation
A scorer using write-through updates the paper scoresheet and radios the update to the stadium's giant screen at the exact same moment, waiting for the screen operator to confirm before moving to the next ball. A scorer using write-back instead jots updates only on the paper sheet ball by ball, and radios a whole over's worth of updates to the screen operator in one batch afterward, moving faster but risking that a torn sheet before the radio call loses those updates entirely.
Step-by-Step Explanation
Step 1
Write arrives at the cache
A write request first hits the caching layer in both strategies.
Step 2
Write-through path
The cache immediately writes through to the database and waits for confirmation before acknowledging the caller.
Step 3
Write-back path
The cache acknowledges the caller immediately and marks the entry as dirty, pending a later flush.
Step 4
Flush and durability
Write-back periodically or eventually flushes dirty entries to the database in batches; write-through has already flushed on every write.
What Interviewer Expects
- Clear articulation of the synchronous-vs-asynchronous database write distinction
- Understanding of the latency vs durability trade-off between the two
- Awareness that write-back risks data loss on cache failure before a flush
- A concrete scenario for when each is appropriate
Common Mistakes
- Saying write-back never writes to the database at all
- Confusing write-through with cache-aside (a read-side pattern)
- Not mentioning the data-loss risk unique to write-back
- Assuming write-through has no performance cost
Best Answer (HR Friendly)
“Write-through writes to the cache and the database at the same time, so they are always in sync but every write is a bit slower. Write-back writes to the cache immediately and updates the database later in batches, which is much faster but carries a small risk of losing recent writes if the cache fails before it flushes to the database.”
Code Example
-- Write-through: application logic does both synchronously
-- cache.set("product:55:price", 19.99)
UPDATE Products SET price = 19.99 WHERE product_id = 55;
-- Caller only gets a success response once BOTH complete.
-- Write-back: application writes to cache only, then later
-- a background flush job batches dirty keys into one statement
UPDATE Products
SET price = 19.99
WHERE product_id = 55;
-- Runs minutes later, batched with other dirty keys,
-- not on the critical path of the original write.Follow-up Questions
- What happens to write-back data if the cache node crashes before a flush?
- How would you batch multiple dirty keys into an efficient database flush?
- When would you choose write-through despite its latency cost?
- How do write-through and write-back interact with cache eviction policies?
MCQ Practice
1. In a write-through cache, when is a write acknowledged to the caller?
Write-through requires both the cache and the underlying database to be updated before the write is considered complete.
2. What is the main risk of a write-back cache?
Because write-back defers the database update, unflushed dirty entries are vulnerable to loss on cache failure.
3. Which strategy generally offers lower write latency to the caller?
Write-back acknowledges the caller as soon as the cache accepts the write, without waiting for the database.
Flash Cards
What is write-through caching? — Writing to the cache and database synchronously, acknowledging only after both succeed.
What is write-back caching? — Writing to the cache immediately and flushing to the database asynchronously later.
Main risk of write-back? — Data loss if the cache fails before dirty entries are flushed to the database.
Main cost of write-through? — Higher write latency since every write must reach both the cache and the database.