Write-Behind (Write-Back) Caching with Redis

Write-through keeps the cache and database consistent by writing to both synchronously, which makes writes as slow as the database. Write-behind takes the opposite bet: write to the cache immediately, acknowledge right away, and persist to the database asynchronously a moment later. Writes become fast because they only touch memory. The catch is that you've introduced a window where committed writes exist only in Redis, so a crash can lose them. This is the highest-performance and highest-risk caching pattern, and knowing exactly what you're trading is essential before using it.

This is part 11 of the Redis Masterclass, following read-through and write-through.

How write-behind works

In write-behind (also called write-back), a write goes to Redis and returns immediately. The database update happens separately, asynchronously, batched with other writes:

1. Application writes to Redis and gets an immediate acknowledgement.
2. The write is queued for persistence.
3. A background process drains the queue and writes to the database, often batching many writes into fewer database operations.

// write is instant: only touches Redis
await redis.hset(`counter:${id}`, 'value', newValue);
await redis.rpush('write_queue', JSON.stringify({ id, value: newValue }));
// a background worker later batches these into the database

The write latency the application sees is just the Redis write, sub-millisecond. The database absorbs the writes later, in efficient batches, which also reduces database load by turning many small writes into fewer large ones.

Why it's fast, and why it's risky

The speed is real and comes from two things: writes only hit memory, and batching amortizes database overhead. For write-heavy workloads (high-frequency counters, metrics, telemetry, view tracking) write-behind can absorb write rates that would overwhelm a database hit synchronously.

The risk is equally real. Between the acknowledged write and the eventual database persist, the data lives only in Redis. If Redis crashes (or the persistence worker dies) in that window, those writes are lost, even though the application was told they succeeded. Write-behind weakens durability: you've told the user "saved" before it's durably saved. That's acceptable for some data and unacceptable for other data, and being honest about which is everything.

What write-behind is right for

The pattern fits data where high write throughput matters and occasional loss of the most recent writes is tolerable:

• Analytics and metrics: page views, event counts, telemetry. Losing a few seconds of counts on a rare crash doesn't matter, and the write volume is high.
• Aggregated counters: likes, view counts, and similar, where the count is a running tally and small inaccuracies self-correct.
• Activity tracking: last-seen timestamps, non-critical logs.

For these, write-behind's throughput is a genuine win and the durability weakness is a fine trade. The common thread is that the data is high-volume and individually low-stakes.

What it's wrong for

The pattern is dangerous for anything where a lost write is a real problem:

• Financial transactions, orders, payments: never write-behind these. A "saved" that vanishes is a serious bug.
• Anything the user is told is permanently saved and would be alarmed to lose.
• Data with no other source of truth: if Redis is the only place the write existed, its loss is total.

The rule: if losing the last few seconds of writes on a crash would be a real incident, don't use write-behind. Use write-through or plain cache-aside with a synchronous database write, and accept the higher latency as the price of durability.

Making it safer

If you use write-behind, a few measures reduce (not eliminate) the risk:

• Enable Redis persistence (AOF, covered later) so Redis itself can recover recent writes after a restart, shrinking the loss window.
• Use a durable queue for the pending writes, like a Redis stream, so the pending-write list survives better than an in-memory structure.
• Keep the flush interval short so the window of unpersisted data is small.
• Monitor the queue depth so you know if persistence is falling behind, which both grows the risk window and signals a problem.

These make write-behind less risky, but they don't make it durable in the way a synchronous database write is. The window shrinks; it doesn't close.

Write-behind is a specialist tool: maximum write speed for high-volume, loss-tolerant data, bought with weakened durability. Use it deliberately for metrics, counters, and telemetry where throughput matters and the occasional lost write is harmless, and keep it far away from anything that must not be lost. The decision is entirely about the data's value, so make it consciously.

Next, we cover refresh-ahead caching, which attacks a different problem: avoiding cache misses entirely by refreshing hot keys before they expire.