Write-behind (write-back)
A caching pattern where writes go to the cache and return immediately; the DB is updated asynchronously later. Fast writes, but the cache is the source of truth until flushed, risking data loss on failure.
- Write-heavy counters, telemetry, ephemeral state.
- When losing recent writes on failure is acceptable.
- Transactional data where durability is required.
- Low-write workloads.
Definition
On a write, update the cache and acknowledge; a background process flushes changes to the DB. The cache holds the latest value; the DB lags. Coalescing merges many writes into one DB write.
Why it exists
Write latency is dominated by the DB. Writing only to the cache makes writes fast and coalesces bursts, ideal for write-heavy, loss-tolerant workloads like counters and telemetry.
How it works
Write → SET cache + enqueue a deferred DB update. A flusher drains the queue to the DB, coalescing repeated writes to the same key. The cache must be durable (or you accept loss) since it holds unflushed state.
Scaling limits
Data loss if the cache dies before flushing. Ordering and consistency across keys are hard. Flush backlog grows under DB slowness, increasing staleness and loss window.
Cost shape
Cheap writes (cache only) + async flush. Blow-ups: loss window on failure and flush backlog under DB degradation.
Alternatives
- Write-through — Durable and consistent, but slower writes.
- Cache-aside — Simpler and safe, but no write coalescing.
Failure modes
- Data loss on cache failure before flush.
- Flush backlog causing large loss windows.
- Reorder bugs in async flush.