scalingestablished · medium operational burden

Write-Through and Write-Behind Caching

Also known as: write-through-cache, write-back-cache, write-behind

Intent

Keep a cache synchronized with the store by writing through it, either synchronously or asynchronously.

Problem

Cache-aside leaves stale windows and forces every caller to manage invalidation, while direct database writes are slow under heavy write load. Teams need either always-fresh caches or faster write acknowledgement.

Forces

•Reads should see recently written data
•Write latency and database throughput are limited
•Durability must not be silently lost
•Cache and store must not diverge

Solution

Overview

These two patterns place the cache in the write path. They differ in when the database learns about a write: before the acknowledgement (write-through) or after it (write-behind).

How it works

Write-through:
  client -> cache -> database -> ack -> client

Write-behind:
  client -> cache -> ack -> client
                 \-> queue -> batch flush -> database

With write-through, the application or a caching library writes to the store, then updates the cache entry. Failure of the database write fails the whole operation, so cache and store agree. The cost is that write latency is the sum of both hops.

With write-behind, the cache holds the newest value and a dirty-set. A background flusher writes dirty keys in batches, often every few hundred milliseconds. If a key is updated ten times between flushes, only the final value reaches the database, which is ideal for counters, presence and last-seen timestamps.

Pitfalls

Treating write-behind as durable. A crash before flush loses data the client was told was saved. Replicate the dirty queue or use a log.
Ignoring ordering. Flushing per key in order is easy; cross-key ordering and foreign-key constraints are not.
Unbounded dirty queues. Apply backpressure when flush lag exceeds a threshold.
Other writers bypassing the cache, which leaves cached values wrong. Make the cache the sole writer.
Caching data on write that is never read, filling memory with cold entries.

Key takeaways

Write-through buys freshness at the price of write latency.
Write-behind buys throughput and latency at the price of durability.
Never use write-behind for data you cannot afford to lose.
Monitor flush lag and cap the dirty queue.

✓ When to Use

•Write-through: read-after-write freshness with a read-heavy mix
•Write-behind: bursty or counter-style writes where only the latest value matters
•When the database is the throughput bottleneck for writes

✗ When Not to Use

•Write-behind for financial or other data that cannot be lost
•Data that is written once and rarely read, where caching wastes memory
•Systems needing multi-row transactional guarantees across cache and store

Pros

+Write-through gives fresh reads without invalidation logic
+Write-behind lowers write latency and coalesces updates
+Database sees fewer, larger writes

Cons

−Write-through adds latency to every write
−Write-behind risks data loss and reordering on failure
−Both need a cache layer that understands the store

Cost Profile

Infrastructure

Cache cluster plus durable queue for write-behind

Operational

Medium: monitor flush lag and failures

Cognitive

High: failure semantics are subtle

Failure Modes

Cache node dies with unflushed writes, losing acknowledged data
Flush backlog grows until memory is exhausted
Database rejects a flushed write after the client was told it succeeded

Real-World Examples

Alternatives

Related Patterns

caching
backpressure

Competency Domains

data statereliability ops