Write-Back

Cache first, persistent write later

With Write-Back, a change is stored in the cache first, after which the application can receive a successful response. Accumulated changes are sent to the primary store later — asynchronously.

application
    |
    v
  cache ----> response
    |
    | later
    v
write queue
    |
    v
primary store

Why writes become faster

The client does not wait for slower persistent storage on the critical path. Several changes to the same value can sometimes be combined before writing, and an update stream can be sent to storage in larger batches.

This approach is useful when write speed is very important and the system can temporarily keep new data in an intermediate layer.

But the cache temporarily becomes the only place with the new version

Until data is flushed, the primary source does not yet know about the change. If the intermediate layer loses data before it is written durably, a change already confirmed to the user can disappear.

That is why Write-Back especially depends on durability of the change queue, retries, write ordering, and failure behavior. The longer the system delays persistent writes, the more data can be “in flight.”

Write-Through and Write-Back optimize different sides

Write-Through waits for the primary store and therefore increases write latency, but a successful operation has already reached persistent storage. Write-Back responds earlier, but moves part of the risk and complexity into asynchronous delivery of changes.