Write-Through Cache
A caching pattern where every write goes to both the cache and the database simultaneously. Ensures consistency but adds write latency.
What is Write-Through Cache?
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.
What it is
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.
How it works under the hood
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.
When to use it and the trade-offs
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.
A concrete example
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.
Where it is used in production
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.
Frequently asked questions
- What is the difference between write-through and write-back caching?
- 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.
- Does write-through caching make reads faster?
- 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.
- What is the main downside of write-through?
- 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.
- When should I not use a write-through cache?
- 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.
- How does write-through compare to cache-aside?
- 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.
Learn Write-Through 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-Through 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-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.