# Write-Through vs Write-Back Cache: The Interview Answer You Must Nail Write-Through vs Write-Back Cache Caching isn’t just about speed — it’s a contract about consistency and durability. When an interviewer asks you to choose between write-through and write-back (write-behind) cache strategies, they’re testing your ability to weigh consistency guarantees against write performance and system complexity. ## Quick definitions - **Write-through:** Every write goes to the cache and the backing store (database) synchronously. Simple and predictable; strong consistency. - **Write-back (write-behind):** Writes go to the cache first and are flushed to the backing store later (often on eviction or in batched intervals). Fast for writes but riskier for durability and consistency. ## Pros and cons ### Write-through - Pros: - Stronger consistency: cache and DB stay in sync after the write returns. - Simpler to reason about and debug. - Safer for critical workloads (financial data, order state). - Cons: - Higher write latency: every write pays the cost of both cache and DB writes. - Fewer gains for write-heavy workloads. ### Write-back - Pros: - Lower write latency: clients return quickly after updating cache. - Efficient for heavy write loads via batching and reduced DB IOPS. - Cons: - Risk of lost or stale data if the cache fails before flushing. - More complex: eviction policies, flush scheduling, and failure handling. - Harder to ensure strong consistency and durability. ## When to pick which - Choose **write-through** when: - You need strong consistency and durability immediately (payments, account balances, inventory control). - Simplicity and predictability matter more than raw write throughput. - Choose **write-back** when: - You have very high write volume and can tolerate eventual consistency. - Latency for the write operation is critical and you can accept complexity to gain throughput. ## Failure modes and mitigations - Risk: data loss if cache crashes before flushing. - Mitigations: write-ahead logs (WAL), persistent cache (AOF/RDB for Redis), replicate cache, use reliable message queues for flush tasks. - Risk: stale reads / read-after-write inconsistency. - Mitigations: read-through for hot keys, strong read-your-writes guarantees at application level, versioning or sequence numbers. - Risk: complexity in eviction and batching logic. - Mitigations: bounded batch intervals, backpressure, and observability (metrics/alerts for flush lag). ## Hybrid and alternatives - **Write-around:** Write directly to DB and populate cache on reads — good when writes rarely hit the same keys. - **Primary-backup or consensus-based approaches:** Use a durable, replicated store as the primary and cache for reads (sacrifices some cache performance for stronger durability). ## How to answer this in an interview (short script) "Caching is more than speed—it's a consistency decision. I’d pick write-through when I need immediate durability and strong consistency (e.g., financial data). I’d pick write-back for high-ingest workloads where eventual consistency is acceptable, but I’d add durability safeguards (WAL/replication) and careful flush/error handling. Ultimately, the choice depends on the consistency requirements versus acceptable write latency and system complexity." ## Quick takeaways - Write-through = simple, predictable, consistent, slower writes. - Write-back = fast writes, higher throughput, more risk and complexity. - In interviews, explicitly state the consistency vs latency trade-off and give a short justification tied to the business use case. #SystemDesign #SoftwareEngineering #TechInterviews