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 every write goes to both the cache and the database simultaneously. Ensures consistency but adds write latency.
In short
A write-through cache is a caching strategy where every write goes to the cache and the backing database in the same operation, before the write is acknowledged as complete. This keeps the cache and database always in sync so any later read from the cache returns current data, at the cost of slower writes.
In short
A write-through cache is a caching strategy where every write goes to the cache and the backing database in the same operation, before the write is acknowledged as complete. This keeps the cache and database always in sync so any later read from the cache returns current data, at the cost of slower writes.
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-Through Cache across a run of lessons, not one page. These 4 alone are about 97 minutes of step-by-step reading, every one with a quiz.
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.
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.
Measured against a real Redis on loopback, a hit costs 0.056 ms against 0.00004 for a local one. Work cheaper than that is made slower by caching it, and at 232 KB the parse was 94 percent of the hit.
Resolving conflicts when offline changes sync with the server. CRDTs, last-write-wins, and merge strategies.
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-Through Cachepay once,
yours for life
A write-through cache sits in front of a slower data store, usually a relational or document database. When the application writes a piece of data, the cache does two things in one step: it updates its own copy and it writes the same value to the database. The write is only reported as successful after both have been updated.
The point is consistency. Because the cache is never allowed to hold a value that the database does not also hold, a read that hits the cache can be trusted. You never serve a fresh write from the cache while the database still has the old value, which is the problem you get with write-back caching.
Write-through is almost always paired with a read strategy like read-through or cache-aside. Writes keep the cache warm and correct; reads then mostly hit the cache instead of the database.
On a write, the flow is fixed: application sends the new value to the caching layer, the caching layer writes it to the database, waits for the database to confirm, updates its own entry, and only then returns success to the application. The two writes happen synchronously, so the slower of the two sets the total latency.
On a read, the application asks the cache first. If the key is present it returns immediately. If it is not present (a cache miss, common for data that was written before the cache existed or that aged out), the system falls back to the database, loads the value into the cache, and returns it. Each cache entry usually carries a TTL so stale or unused keys expire on their own.
A subtle detail: write-through writes everything, including data that may never be read again. If you write a million log rows you will never query, you have paid to cache all of them. That is why some teams add a TTL or only cache-on-write for hot key prefixes.
Reach for write-through when reads heavily outnumber writes and you cannot tolerate stale reads: user profiles, account balances, product catalog entries, configuration that is read constantly but changed rarely. The synchronous double write is paid once per change and saved on every subsequent read.
The cost is write latency. Every write now waits on both the cache and the database, so a write that took 5 ms against the database alone might take 6 to 8 ms through the cache. Compare this with write-back, which acknowledges the write after only touching the cache and flushes to the database later. Write-back is faster on writes but can lose data if the cache node dies before the flush, and it lets the cache and database drift apart temporarily.
Write-through gives up nothing on durability or consistency and gives up some write speed. If your workload is write-heavy or write latency is on a critical path, write-through is the wrong default and you should look at write-back or cache-aside without write population.
Picture an e-commerce service tracking inventory counts in Postgres with Redis in front. When a unit sells, the service writes the new count through Redis: Redis updates Postgres, confirms, updates its own key for that SKU, then returns. The very next page view that reads that SKU hits Redis and sees the correct count without touching Postgres.
If the same system used write-back instead, the sale would update only Redis and acknowledge instantly, then flush to Postgres a moment later. Faster checkout, but if Redis crashed in that window the database would still show the old count, and a report run straight against Postgres would be wrong. Write-through trades that small write delay for never having that gap.
Redis
Commonly configured as a write-through layer in front of Postgres or MySQL, either via application logic or RedisGears/write-through modules so every write also lands in the source of record.
Amazon DynamoDB Accelerator (DAX)
DAX runs as a write-through cache for DynamoDB: writes go through DAX to the table and the cache is updated in the same call, so reads stay consistent.
Ehcache / Hibernate second-level cache
Java applications use Ehcache in write-through mode so persisting an entity updates both the cache and the database transactionally.
NCache
Provides a built-in write-through provider where the cache calls into your data source on every write, keeping the distributed cache and database aligned.
Write-through writes to both the cache and the database before acknowledging, so they are always in sync but writes are slower. Write-back writes only to the cache, acknowledges immediately, and flushes to the database later, which is faster but risks data loss if the cache fails before the flush and allows temporary inconsistency.
Indirectly, yes. Write-through itself only governs writes, but because every write also populates the cache, the data is already there for the next read. Combined with a read-through or cache-aside read path, most reads hit the cache and skip the database.
Higher write latency. Each write waits on both the cache and the database synchronously, so it is slower than writing to the database alone. It also caches data that may never be read again, wasting cache memory unless you add a TTL.
Avoid it for write-heavy workloads or when write latency is on a hot path, since the extra synchronous write hurts. It is also overkill for data you write but rarely read; cache-aside or write-back fits those better.
In cache-aside the application writes only to the database and lets the cache fill lazily on a read miss, often invalidating the cache key on write. Write-through actively populates the cache on every write, so reads after a write are guaranteed warm and consistent, but writes are slower.
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-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.
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-Through 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-Through Cache lessoncourse 1
From absolute beginner to principal engineer, drawn step by step.
Asked about Write-Through 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.
