We use analytics cookies.We use cookies to analyze site traffic and improve your experience.
Loading...
System Design and AI Engineering, by Roni Das. 984 interactive lessons.
Start LearningFoundation · Caching Strategies
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.
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.
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.
Learn it in the course
This page is the free part.
₹1,111 in India$25 everywhere elseonce, for the whole course
The System Design course covers Write-Behind Cache across a run of lessons, not one page. These 4 alone are about 99 minutes of step-by-step reading, every one with a quiz.
How a write-back cache holds writes and flushes them later. Measured tests show how the flush interval trades fewer database writes for data at risk.
Write-through took the read hit rate from 71.5 percent to 68.3 on uniform writes, and from 59.5 to 71.9 on correlated ones. It is a bet on whether your writes predict your reads.
The cache your own code manages, the race hiding in its default pattern, and how often that race actually fires.
Cache-aside is said to degrade gracefully when the cache fails. Measured, unwrapped it answered 0.0 percent of requests, and wrapped it answered 13.0, which is exactly the database's capacity.
all part of
System Design Masterclass
770 lessons · about 287 hours · 18 free to read
₹1,111in India, by UPI
$25everywhere else, by PayPal
It is really nice and good Please join the course
You own this course
Continue with Write-Back Cachepay once,
yours for life
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
The industry examples in “The next question”:
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.
This page explains the idea. The "Write-Back Cache" lesson builds it up step by step, with diagrams. It is part of the System Design Masterclass course, which has 770 lessons. 18 of them are free to read. You pay once and keep it for life, with no subscription.
Open the Write-Back Cache lessoncourse 1
From absolute beginner to principal engineer, drawn step by step.
Asked about Write-Behind Cache in an interview?
Each question has why it is asked, a full answer, what the interviewer listens for, the follow-ups, the common mistakes and a diagram (268 diagrams in all). A PDF you keep, junior to staff level.
India: UPI, cards or netbanking through Razorpay. Elsewhere: card or PayPal. Download at once from My packs.
