Write-Behind Cache
A caching pattern where writes go to the cache first and are asynchronously flushed to the database later. Fast writes but risks data loss on cache failure.
What is Write-Behind Cache?
In short
A write-behind cache (also called write-back) is a caching pattern where the application writes data to the cache and gets an immediate acknowledgment, while the cache asynchronously flushes those writes to the backing database a short time later in batches. It makes writes very fast and absorbs traffic spikes, but data sitting only in the cache is lost if the cache fails before it is persisted.
What a write-behind cache actually is
In a write-behind cache, the cache is the first place a write lands. The application sends an update, the cache stores it in memory and immediately returns success. The matching write to the durable database happens later, on a background schedule, instead of inside the request.
This is the opposite of write-through caching. With write-through, the database write must finish before the application gets a response, so the client waits for the slowest storage layer. With write-behind, the client only waits for the in-memory write, which is typically under a millisecond.
The word behind describes the timing. The persistent store is always slightly behind the cache, catching up on a delay measured in milliseconds to a few seconds. During that window the cache holds the only fresh copy of the data.
How it works under the hood
The cache keeps a queue, often called a dirty queue, of entries that have been changed but not yet written to the database. A background worker drains this queue on a timer or once the queue reaches a size threshold.
The big win comes from coalescing and batching. If the same key is updated five times in two seconds, the cache can persist just the final value once instead of five separate database writes. Many small updates collapse into a few larger batch writes, which databases handle far more efficiently than a flood of individual statements.
Most implementations let you tune two knobs: the flush interval, for example flush every 500 milliseconds, and the batch size, for example flush once 1000 dirty entries pile up, whichever comes first. Lowering these reduces the data-loss window but gives up some batching benefit. Raising them improves throughput but widens the gap where unflushed data exists only in memory.
When to use it and the trade-offs
Reach for write-behind when write volume is high, writes are bursty, and the data can tolerate a small risk of loss. Counters, view counts, like tallies, telemetry, session activity, and game state are good fits. Losing the last second of a view counter rarely matters; losing a payment record does.
The core trade-off is durability versus speed. Because the database lags the cache, a cache crash or power loss can drop every entry still in the dirty queue. Production systems reduce this by replicating the cache, using append-only logs, or persisting the queue to disk so it survives a restart.
There are two more sharp edges. First, if another service reads directly from the database while a write is still in the queue, it sees stale data, so the database is no longer the single source of truth in real time. Second, a write to the database can fail after the application already got a success response, which means error handling moves into the background worker with retries and dead-letter handling instead of failing the original request.
A concrete example
Imagine a video platform tracking view counts. Every play increments a counter. At peak, a popular video gets 50,000 plays per minute. Writing each increment straight to Postgres would be over 800 writes per second on a single hot row, which causes lock contention and slows everything down.
With write-behind, each play increments the count in Redis instantly. A background job flushes the accumulated total to Postgres every second. Those 50,000 increments become roughly 60 database writes per minute instead of 50,000, and the user never waits on the database.
The accepted cost is that if Redis dies, you might lose up to one second of counts for that video. For a view counter that is fine. The same pattern would be unacceptable for the platform's billing ledger, which uses synchronous, durable writes instead.
Where it is used in production
Redis
Commonly used as a write-behind buffer for counters and metrics, with a background job flushing aggregated values to the primary database.
Write-behind in CPU caches
Modern CPUs use write-back caches in hardware, holding modified cache lines and writing them to main memory only when the line is evicted.
Ehcache and Hazelcast
These JVM caching libraries ship a built-in write-behind mode that queues cache updates and persists them to a backing store on a configurable interval and batch size.
Operating system page cache
Linux buffers file writes in the page cache and flushes dirty pages to disk later via background writeback, which is why an unclean shutdown can lose recent unsynced writes.
Frequently asked questions
- What is the difference between write-behind and write-through caching?
- Write-through writes to both the cache and the database before responding, so the client waits for the database and data is always durable. Write-behind writes only to the cache, responds immediately, and persists to the database asynchronously, which is faster but risks losing unflushed data if the cache fails.
- Is write-behind the same as write-back?
- Yes. Write-behind and write-back are two names for the same pattern. Write-back is the more common term in CPU and hardware caching, while write-behind is used more often in application and database caching.
- When should I not use a write-behind cache?
- Avoid it for data that cannot tolerate any loss, such as financial transactions, orders, or audit logs. In those cases the brief window where data lives only in the cache is too dangerous, so use a synchronous, durable write path instead.
- How does write-behind reduce database load?
- It coalesces and batches writes. Repeated updates to the same key collapse into a single persisted value, and many individual writes are grouped into fewer batch operations, which cuts the number of database round trips dramatically for write-heavy workloads.
- What happens if the database write fails after the cache already acknowledged?
- Because the client already got a success response, the failure is handled in the background worker. Typical strategies are automatic retries with backoff, alerting, and moving the failed entry to a dead-letter queue so it can be replayed or inspected later.
Learn Write-Behind Cache hands-on
This page explains the idea. The full lesson lets you step through the ring as servers join and leave, read the implementation, and check yourself with a quiz. It is one of 760+ lessons in the System Design Masterclass, from your first API call to distributed consensus. Eleven Foundation lessons are free, no signup. Lifetime access is ₹499 in India or $7.99 worldwide, one payment, no subscription.
Related lessons
Lessons that touch on Write-Behind Cache as part of a larger topic.
See also
Related glossary terms you might want to look up next.
Cache-Aside
A caching pattern where the application checks the cache first; on a miss, it fetches from the database and populates the cache. Also called lazy loading.
Write-Through Cache
A caching pattern where every write goes to both the cache and the database simultaneously. Ensures consistency but adds write latency.
Caching
Storing frequently accessed data in a faster storage layer so you don't have to fetch it from the original (slower) source every time.
CDN
A network of servers distributed globally that caches content close to users. Netflix uses CDNs to stream video from servers near you, not from one central location.
Cache Eviction
The process of removing entries from a cache when it's full. Common policies: LRU (least recently used), LFU (least frequently used), FIFO (first in, first out).
TTL
Time To Live: how long a cached entry, DNS record, or packet is valid before it expires and must be refreshed or discarded.