Write-Behind (Write-Back) Cache
Writes go to the cache immediately and are asynchronously flushed to the database in the background, trading durability risk for dramatically lower write latency.
Write-behind (also called write-back) caching writes data to the cache first and acknowledges the write immediately. A background process then asynchronously persists the cached writes to the database, often batching multiple writes together for efficiency. This gives you near-instant write latency and the ability to coalesce rapid updates to the same key. The risk is data loss: if the cache crashes before the background flush, uncommitted writes are lost.
Read/Write Pattern
Writes go to the cache and return immediately. A background process asynchronously flushes cached writes to the database, often batching and coalescing them. Reads always check the cache first.
Consistency
Eventual consistency. The cache always has the latest value, but the database lags behind by the flush interval. Systems reading directly from the database bypass the cache and see stale data.
Failure Mode
If the cache crashes before flushing pending writes, those writes are lost. This is the primary risk. Mitigations include cache replication, write-ahead logs, persistent message queues, and shorter flush intervals. If the database is unavailable, writes accumulate in the cache queue; if the queue overflows, writes may be rejected.
Likely Follow-Up Questions
- How would you prevent data loss in a write-behind cache?
- Explain write coalescing and give an example where it provides a 100x reduction in database writes.
- How do you handle the case where the database flush fails for some entries in a batch?
- When would you choose write-behind over write-through?
- How would you implement write-behind using Redis and a message queue?
Source: editorial — Synthesized from standard distributed systems caching literature and production engineering best practices.