# Write-through vs Write-back cache > Write-through waits for the backing store before acknowledging a write; write-back acknowledges from the cache layer and persists to the backing store later. Choose write-through when acknowledged writes must already be in the database, and write-back when lower write latency or write coalescing justifies a more complex durability and recovery design. Source: https://sysround.com/compare/write-through-vs-write-back Updated: 2026-11-05 ## Side by side | | Write-through | Write-back cache | |---|---|---| | Acknowledgment | After backing-store write succeeds | Before backing-store write completes | | Write latency | Includes backing-store latency | Depends on cache-layer durability policy | | Backing-store traffic | Usually one write per update | Can batch or coalesce updates | | Durability | Uses backing store's durability guarantee | Requires protection for unflushed writes | | Database readers | Acknowledged writes are persisted; replicas may lag | May miss acknowledged, unflushed updates | | Cache eviction | Persisted entries can be discarded | Dirty entries need flushing or durable recovery | | Database outage | Writes cannot complete normally | Can buffer writes within safe capacity | | Operational burden | Handle partial failures and cache coherence | Also handle backlog, replay, and flush ordering | ## The differences that matter The main distinction is the acknowledgment boundary. With write-through, the write path updates the cache and backing store synchronously before reporting success. With write-back, also called write-behind, the cache holds a dirty value that has not yet reached the backing store. Neither label alone specifies replication, transaction isolation, or read consistency. Write-back can reduce database work when repeated updates to one key can be replaced by its latest value. For example, several location updates may become one persisted snapshot. That optimization is invalid when every intermediate event matters, such as financial ledger entries or an audit trail. Batching preserves individual updates; coalescing discards intermediate states. Write-back moves durability responsibility into the cache layer. An in-memory acknowledgment can lose data if the node fails before flushing. A durable log and an appropriate replication acknowledgment policy can protect pending writes, but they add latency and recovery work. State exactly which failures an acknowledged write survives. Write-through avoids a pending-write backlog, but it does not make the cache and database an atomic unit. A database write can succeed while a cache update fails, and concurrent cache fills can reintroduce stale values. Both approaches need explicit handling for partial failures, concurrent updates, and stale readers. Write-back needs bounded buffering and ordered recovery. Retried or concurrent flushes must not overwrite a newer value with an older one, so use per-key ordering or conditional version checks. Track dirty-data age and backlog size, protect dirty entries from unsafe eviction, and apply backpressure when persistence falls behind. ## Choose Write-through when - A successful response must mean the authoritative database has accepted the write under its configured durability policy. - Other services read directly from the database and cannot tolerate an additional cache-to-database persistence delay. - The database can sustain the write workload, and its latency fits the request budget. - You want cache loss to affect read performance rather than erase the only copy of acknowledged updates. ## Choose Write-back cache when - The workload repeatedly overwrites the same keys, and only the latest state needs to reach the database. - The request latency budget cannot include a backing-store write, but can include the chosen cache or durable-log acknowledgment. - Short database outages or traffic bursts should be absorbed by a bounded buffer with explicit backpressure. - Database readers can tolerate delayed persistence, and the team can operate durable buffering, replay, version checks, and backlog monitoring. ## Worked example: Persisting the latest vehicle location Suppose 10,000 vehicles each send 10 location updates per second, producing 100,000 updates per second. Dispatch reads the latest location from the cache, while the database needs only a recent snapshot, not a complete route history. With write-through, the database must handle roughly 100,000 updates per second. With write-back and one flush per key per second, coalescing can reduce that to roughly 10,000 database updates per second. These are workload assumptions, not benchmark results. Define a one-second persistence target during healthy operation, protect pending writes according to the required failure tolerance, and bound the outage backlog. If every GPS sample must be retained, use a durable event stream rather than discarding intermediate updates. ## In the interview - Start with the success contract: after acknowledgment, where does the write exist, and which failures can destroy it? Expect questions about node loss, replica failover, and regional failure. - Quantify update rate, distinct keys per flush interval, and the persistence delay budget. Explain whether batching merely reduces request overhead or coalescing actually reduces the number of database updates. - Walk through a database outage and a cache restart. For write-back, describe buffer capacity, replay, dirty-entry eviction, and when you reject or slow new writes. - Trace two concurrent updates to the same key. Explain read routing, version checks, retry safety, and how an older flush is prevented from overwriting newer state. ## Common mistakes - Claiming write-through automatically provides strong consistency across cache replicas, database replicas, and bypassing readers. - Calling write-back durable without specifying whether acknowledgment requires a durable log, replication, or both. - Assuming write-back always reduces database writes, even when every update must be preserved individually. - Treating dirty entries like ordinary evictable cache data, or allowing an unbounded flush backlog during a database outage. ## Interview questions where it comes up - [Design a distributed cache](https://sysround.com/questions/design-distributed-cache): Persistence policy determines whether dirty entries can be evicted and what ownership changes or replica failover must preserve. - [Design a ride hailing app like Uber](https://sysround.com/questions/design-uber): High-frequency vehicle locations expose the trade-off between persisting every update and coalescing latest-state snapshots. - [Design a distributed key-value store](https://sysround.com/questions/design-key-value-store): The acknowledgment boundary, durable logging, and ordered flushing are central to explaining write durability and recovery. - [Design Facebook likes at scale](https://sysround.com/questions/design-facebook-likes): Cached counts may be persisted asynchronously, but authoritative like/unlike state and replay-safe aggregation must remain correct. ## FAQ ### What is the difference between write-through and write-back caching? Write-through waits for the backing-store write before reporting success. Write-back reports success before that write completes and persists the update asynchronously. The difference changes latency, failure recovery, and what database readers can observe. ### Is write-back the same as write-behind? In application caching discussions, write-back and write-behind usually describe the same asynchronous persistence pattern. Implementations differ in when they flush, whether they coalesce updates, and how they protect pending writes. Clarify those details instead of relying on the name. ### Can write-back caching lose data? Yes, if an acknowledged update exists only in volatile cache memory and that memory is lost before persistence. A durable log and replication can protect pending updates against specified failures, but replication alone does not define a durability guarantee. Recovery also needs safe replay and ordering so an older update cannot replace newer state. ## Related concepts - [Caching strategies](https://sysround.com/concepts/caching-strategies) - [Cache invalidation](https://sysround.com/concepts/cache-invalidation) - [Write-ahead log](https://sysround.com/concepts/write-ahead-log) - [Backpressure](https://sysround.com/concepts/backpressure) - [The dual-write problem](https://sysround.com/concepts/dual-writes) --- SysRound (https://sysround.com) is an AI practice tool for system design interviews: a voice or typed AI interviewer, a shared whiteboard, then feedback on every skill and a model answer. Its feedback is AI-generated and can be wrong.