阅读中文版本

Write-Behind Caching

A write-behind cache acknowledges the write after updating the cache and flushes to the backing store asynchronously, trading durability for latency.

Definition

Write-behind caching, also called write-back, updates the cache immediately and defers persisting to the underlying store by queueing the change and applying it later.

It is chosen when write latency matters more than strict durability, such as counters, telemetry, and session touch updates. Compared to simpler alternatives, this concept fits best when the trade-off it represents is the one the system actually cares about.

When to use it

A common use case is applying it at the boundary where the cost of getting it wrong is highest, and the scenario usually involves a concrete guarantee the system must uphold. Unlike an ad hoc approach, it makes that guarantee explicit, reviewable, and testable.

How it works

The client sees low latency because the write returns once the cache is updated, while a background process drains the pending changes to the durable store.

If the process or node crashes before the flush, the queued changes can be lost, so the deferred queue must itself be durable for data that cannot be dropped.

Trade-offs and alternatives

Ordering and conflict matter because later writes to the same key must not be overwritten by older queued writes, which requires per-key sequencing. The main drawback is the extra complexity it introduces, so the benefit should clearly outweigh that cost before a team adopts it.

Common misconceptions

A persistent misconception is that write-behind guarantees the write reaches the database eventually under all failures. Another is that it is a drop-in replacement for a synchronous commit. For example, an engineer who assumes otherwise may design around a guarantee that does not actually exist, which only becomes obvious under load or failure.

Anti-patterns to avoid

Two recurring anti-patterns are to using write-behind for financial records that must survive a crash and to queueing flushes in memory only, without persistence. Both tend to surface as hard-to-debug production issues rather than obvious test failures. Related concepts include Cache Partitioning via Consistent Hashing, Edge Caching at the CDN, Request Deduplication.