Write-Behind Cache

A write-behind (or write-back) cache acknowledges writes as soon as the cache is updated, then persists them to the backing store asynchronously in the background. By decoupling the slow store from the write path, it absorbs bursts and dramatically increases write throughput.

How It Works

On a write the cache records the new value and marks the entry dirty, then returns immediately. A background flusher drains dirty entries to the database, often with batching and coalescing: multiple updates to the same key collapse into one store write, and many keys are written in a single batch. Flush triggers include a timer, a dirty-entry threshold, or queue pressure.

Reads are served from the cache, so they see writes instantly even before persistence. The buffer of pending writes is the cache's risk surface: if the process crashes before the flush, unpersisted writes are lost unless the buffer is itself durable (for example, backed by an append-only log or a replicated store).

When to Use It

Use write-behind for write-heavy or bursty workloads where some risk of recent-write loss is acceptable or mitigated: metrics aggregation, view counters, telemetry, leaderboards, and high-rate event ingestion. Batching turns thousands of small writes into a few efficient bulk operations, which is especially valuable for stores with high per-write overhead.

Trade-offs

The central trade-off is durability versus throughput. Buffered writes can be lost on failure; ordering across keys may be relaxed; and the database lags the cache, so external readers see stale data. Error handling is harder: a flush can fail after the caller has been told the write succeeded, requiring retry queues and dead-letter handling. Make the flush idempotent so retries do not double-apply, and bound the buffer to avoid unbounded memory growth.

Related Patterns

Write-through-cache is the synchronous, durable counterpart; read-through-cache provides the matching read path. The idempotent-writer pattern is essential for safe flush retries, and event-sourcing offers a durable alternative log of changes.

Example

A real-time analytics service increments per-article view counters in Redis on every request and returns immediately. A background worker flushes accumulated counters to PostgreSQL every five seconds in a single batched upsert. Millions of increments per minute become a handful of database writes, and the small window of unflushed counts is acceptable for view statistics.