What Is Write-Behind (Write-Back) Caching and When Should You Use It?

Write-behind caching, also called write-back caching, writes a new value to the cache immediately and to the database later, in the background. The application gets a success response as soon as the cache holds the value. A write therefore takes a fraction of a millisecond instead of the few milliseconds a database round trip costs. The price is a window between the cache write and the database write. If the cache node fails inside that window, the data that was not yet written is lost.

Use it when writes are frequent and a small loss is tolerable, such as view counters, analytics events, and session state. Do not use it for money or inventory.

How write-behind works, step by step

1. The application writes a key and value to the cache and receives success at once.
2. The cache marks the entry as dirty, meaning newer than the database copy. It does this with a flag on the entry or by appending the key to a write queue.
3. A background writer wakes on a schedule, often every 1 to 5 seconds, or when the queue reaches a size limit.
4. The writer flushes the dirty entries to the database in one batch, often hundreds of rows in a single statement or transaction.
5. Repeated writes to the same key inside one interval are coalesced, meaning only the latest value is written. So 1,000 increments to one counter become one database write.
6. Reads are served from the cache, so a reader sees the new value even before the database has it.

Step 5 is where the saving comes from. Write-through, which writes the cache and the database inside the same request, would have sent all 1,000 increments to the database. The write-through and read-through patterns are explained in What is Read-Through vs Write-Through Cache?.

Where write-behind is used

CPU caches. The L1 and L2 caches in a modern processor use write-back as the default policy. A modified cache line is marked dirty and written to main memory only when it is evicted. That keeps the memory bus free for other work.

Caching libraries. Ehcache supports write-behind through a cache writer with a configurable batch size and maximum delay. Hazelcast implements it in its MapStore. Setting write-delay-seconds above zero turns write-through into write-behind, and the cluster flushes all dirty entries at that interval. Redis has no built-in write-behind. The application treats Redis as the fast layer, and a separate worker drains a Redis list or stream of dirty keys into the database.

ORMs. Hibernate calls its session behavior transactional write-behind. Changes to objects are held in memory and flushed as batched SQL when the transaction commits. That is write-behind inside one transaction, and it does not survive a crash before commit.

The durability risk and how to reduce it

The risk is that a crash destroys dirty entries that exist only in memory. Three mitigations reduce it, and production systems usually use at least two.

Replicate the cache. Hazelcast keeps one backup copy of each entry on another node by default, so a single node failure loses no dirty entries. Redis replication does the same. A replica receives the write a few milliseconds after the primary, so a tiny window remains.

Persist the write queue. Append each dirty key to a durable log before confirming the write. A Kafka topic or a Redis Stream with append-only persistence enabled both work. On restart, the writer replays the log from the last flushed position.

Cap the flush delay. A 5-second delay means a crash loses at most 5 seconds of writes. A 500-millisecond delay loses at most half a second. Cap the number of dirty entries too, so that a slow database does not let the queue consume all cache memory.