Write-Through vs Write-Back Cache: What is the Difference?
Understand write-through vs write-back caching: consistency, durability risk, and latency trade-offs explained with system design examples.
Expected Interview Answer
Write-through caching writes to the cache and the underlying database synchronously on every write, trading extra write latency for strong consistency, while write-back caching writes only to the cache immediately and flushes to the database later, trading durability risk for lower write latency.
In write-through, every write request updates the cache and blocks until the database write also completes, so the cache and database are never out of sync and a crash never loses acknowledged data. This costs write latency because two systems must confirm the write before the client gets a response. In write-back (also called write-behind), the write only touches the cache and returns immediately, with a background process later flushing dirty entries to the database in batches, which dramatically reduces write latency and database load. The risk is that if the cache node crashes before flushing, unflushed writes are lost, so write-back is typically paired with replication or a write-ahead log for durability. The choice depends on the workload: write-through suits systems where correctness after a crash matters most (financial ledgers), while write-back suits systems that tolerate small data-loss windows for much higher write throughput (analytics counters, session data).
- Write-through guarantees the database is never stale relative to the cache
- Write-back dramatically cuts write latency and database write load
- Choosing correctly per workload balances durability against throughput
- Batched flush in write-back reduces total I/O operations
AI Mentor Explanation
Write-through is like a scorer updating both the handwritten scorebook and the electronic scoreboard the instant a run is scored, waiting until both confirm before play resumes. Write-back is like jotting the run on a scratchpad immediately and only transcribing a batch of overs into the official scorebook at the drinks break. The scratchpad approach is faster in the moment, but if it gets lost before the transcription, those runs are gone. That trade-off between instant dual-confirmation and delayed batch-recording is exactly write-through versus write-back.
Step-by-Step Explanation
Step 1
Client issues a write
A write request for a key arrives at the caching layer.
Step 2
Write-through path
The cache updates its entry and synchronously writes to the database, only acknowledging once both succeed.
Step 3
Write-back path
The cache updates its entry, marks it dirty, and acknowledges immediately without waiting on the database.
Step 4
Background flush
A flusher periodically writes dirty write-back entries to the database in batches, reducing I/O.
What Interviewer Expects
- Clear distinction between synchronous (write-through) and deferred (write-back) database writes
- Named trade-off: consistency and durability vs write latency and throughput
- Awareness that write-back needs replication or a WAL to mitigate data loss risk
- Ability to pick the right strategy for a given workload example
Common Mistakes
- Confusing write-back with write-around (which skips the cache on write)
- Not mentioning the data-loss risk window in write-back on crash
- Assuming write-through has no downside beyond latency
- Failing to give a concrete workload example for each strategy
Best Answer (HR Friendly)
“Write-through caching saves data to the cache and the database at the same time, so nothing is ever out of sync but writes take a bit longer. Write-back caching saves to the cache first and updates the database later in batches, which is much faster but carries a small risk of losing very recent writes if something crashes before that batch completes.”
Code Example
async function writeThrough(key, value, cache, db) {
cache.set(key, value);
await db.write(key, value); // block until durable
return { durable: true };
}
async function writeBack(key, value, cache, dirtyQueue) {
cache.set(key, value);
dirtyQueue.push({ key, value, ts: Date.now() });
return { durable: false }; // flushed later
}
// Background flusher for write-back
async function flushDirtyEntries(dirtyQueue, db, batchSize = 100) {
const batch = dirtyQueue.splice(0, batchSize);
if (batch.length === 0) return;
await db.batchWrite(batch);
}Follow-up Questions
- How does write-around differ from both write-through and write-back?
- How would you mitigate the data-loss risk in a write-back cache?
- Which strategy would you pick for a financial ledger, and why?
- How does eviction interact with dirty entries in a write-back cache?
MCQ Practice
1. What happens on a write in write-through caching?
Write-through updates both the cache and the database and only returns success once both writes complete, keeping them consistent.
2. What is the main risk of write-back caching?
Because write-back defers the database write, unflushed dirty entries can be lost if the cache node fails before the batch flush.
3. Which workload is the best fit for write-back caching?
Write-back trades a small durability risk for much higher write throughput, making it well suited to high-volume, loss-tolerant workloads like counters.
Flash Cards
Write-through caching? — Writes to cache and database synchronously; consistent but slower writes.
Write-back caching? — Writes to cache immediately, flushes to database later; faster but risks data loss on crash.
Main write-back mitigation? — Pair with replication or a write-ahead log so dirty entries survive a crash.
Example write-through use case? — Financial ledgers, where the database must never be stale relative to the cache.