# Write-Through vs Write-Back Cache: The Interview Answer You Must Nail Write-Through vs Write-Back Cache # Write-Through vs Write-Back Cache: The Interview Answer You Must Nail Caching isn’t just about speed — it’s a consistency contract. When you pick a caching write policy you’re choosing how and when your writes become durable and visible. Interviewers often expect a crisp explanation plus reasoning for trade-offs. Here’s a simple, interview-ready breakdown and guidance for when to use each. ## What they are - **Write-through**: Every write is written to the cache and to the backing store (DB) synchronously. The cache and DB are updated together. - **Write-back (write-behind)**: Writes are written to the cache immediately and flushed to the backing store later (on eviction, periodically, or batched). The backing store is updated asynchronously. ## Key trade-offs Write-through - Pros: - Stronger consistency: reads from cache reflect the most recent writes. - Simpler failure semantics and easier recovery. - Predictable correctness — good for critical data (payments, account balances). - Cons: - Slower writes (every write touches DB synchronously). - Higher write latency and increased DB load. Write-back - Pros: - Much faster writes (write to cache only), good for write-heavy workloads. - Can batch and coalesce writes to reduce DB load and increase throughput. - Cons: - Risk of data loss if the cache crashes before flushing to DB (unless you add durability mechanisms). - More complex eviction and flush logic; harder to reason about correctness. - Potential for stale data if reads bypass the cache or if multiple replicas aren’t coordinated. ## Practical considerations - Durability: If you can’t tolerate lost updates (banking, billing), prefer write-through or ensure strong durability for the cache (replication, write-ahead logs, or immediate persistence). - Performance: If ultra-low write latency and high throughput matter and occasional risk is acceptable, write-back with careful batching may be appropriate. - Complexity: Write-back requires careful handling of eviction, crash recovery, ordering, and concurrency. Add queues, checkpoints, or a WAL to mitigate risk. - Read patterns: If reads are frequent and must reflect recent writes, write-through simplifies correctness. ## Implementation patterns & mitigations - Use write-back with a durable queue or replication so that cache crashes don’t lose data. - Batch flushes during low traffic periods to reduce DB pressure. - Combine approaches: e.g., write-through for critical keys, write-back for non-critical high-volume writes. - Consider cache-aside for reads with synchronous writes to the DB when appropriate. ## Interview-ready answer (short) "Write-through writes synchronously to both cache and DB, giving strong consistency and simpler recovery at the cost of higher write latency. Write-back writes to cache first and flushes to DB later for much faster writes, but introduces risk of lost or stale data and requires more complex eviction/flush logic. Choose based on whether you need strict consistency/durability (write-through) or you prioritize write performance and can accept additional complexity and risk (write-back)." ## Quick decision checklist - Use write-through when: correctness/durability is paramount (finance, critical state), and extra write latency is acceptable. - Use write-back when: write performance is critical, you can tolerate complexity and mitigate durability risks (analytics, buffers, some leaderboards). Answering clearly and stating the trade-offs — especially which guarantees you’re giving up or preserving — is the key to nailing this interview question. #SystemDesign #SoftwareEngineering #TechInterviews