Read-Through vs Write-Through Cache
Updated June 8, 2026You've decided to add a cache. Now the question is: how does data actually get in and out of it? Who is responsible for populating the cache? Who handles writes? The answers to these questions define your caching pattern, and picking the wrong one is a common source of bugs, stale data, and missed performance gains.
Two of the most fundamental patterns are read-through and write-through. They answer different questions. Read-through is about how reads work. Write-through is about how writes work. You'll often use them together.
Read-Through Cache
In a read-through cache, the cache itself is responsible for fetching from the database on a miss. Your application only ever talks to the cache — it never goes directly to the database.
Here's the flow:
- Application asks the cache for a key
- Cache hit? The cache returns the value immediately
- Cache miss? The cache fetches the data from the database, stores it, then returns it to the application
Read-through: on a miss, the cache fetches from the database itself. The application never queries the database directly.
Your application code stays clean. No "check cache, if miss then query DB, then populate cache" logic scattered everywhere. The cache library or a middleware layer handles all of that.
The Code Difference
Without read-through (cache-aside — you manage it):
function getUser(userId) {
const cached = redis.get(`user:${userId}`);
if (cached) return cached;
const user = db.query('SELECT * FROM users WHERE id = ?', userId);
redis.set(`user:${userId}`, user, { ttl: 300 });
return user;
}With read-through (the cache manages it):
function getUser(userId) {
return cache.get(`user:${userId}`); // cache handles the miss internally
}The logic is the same. The difference is who owns it.
Pros of Read-Through
- Simpler application code — no cache management logic leaking into business logic
- Automatic cache population — data gets cached the first time it's requested, nothing more, nothing less
- Coalescing concurrent misses — a good read-through cache will merge multiple simultaneous misses for the same key into a single database query
Cons of Read-Through
- First request is always slow — on a cold start or after a cache eviction, the very first request for any key pays the full database cost
- Less control — the cache decides when and how to populate itself; if you need complex population logic, this can be awkward
- Stale data on updates — if the underlying data changes, the cache won't know until the TTL expires (unless you explicitly invalidate)
When to Use Read-Through
Read-through is great for read-heavy workloads where data doesn't change often. Think product catalogs, user profiles, configuration data. The pattern shines when the same keys are requested repeatedly and the data changes infrequently enough that TTL-based staleness is acceptable.
Write-Through Cache
Write-through answers the question: what happens when data changes? In a write-through cache, every write goes to the cache and the database simultaneously. They're updated in lockstep.
Here's the flow:
- Application writes a value
- Write goes to the cache
- Write immediately propagates to the database
- Only after both succeed does the write return
Write-through: every write goes to cache and database simultaneously, keeping them permanently in sync.
Pros of Write-Through
- Cache is always fresh — by definition, the cache and database are always in sync (for data that's been written through)
- No stale reads after writes — a user who just updated their profile will immediately see the new version
- Works well with read-through — pair them together and you get a coherent system: reads are always served from cache, writes always update both
Cons of Write-Through
- Write latency increases — you're now doing two writes synchronously (cache + database) instead of one. If the cache write adds 1ms, every write pays that tax.
- Cache fills with write-once data — if you write data that's never read, you've wasted cache memory. Every write is cached even if nobody will ever ask for that key.
- Not atomic by default — if the database write succeeds but the cache write fails (or vice versa), you have inconsistency. You need careful error handling.
When to Use Write-Through
Write-through is best when your reads and writes are balanced, and freshness is important. If users expect to see their changes reflected immediately, think shopping cart updates, user settings, real-time dashboards, write-through ensures the cache stays current without needing a complex invalidation strategy.
Read-Through + Write-Through Together
These two patterns are designed to work as a pair.
Read-through handles the read path: cache misses are automatically populated from the database. Write-through handles the write path: updates flow to both cache and database.
The result is a cache that's always warm (reads populate it) and always fresh (writes update it). This is close to how managed caching layers like AWS ElastiCache and Azure Cache for Redis are configured when used in caching-layer mode.
The combination is powerful but comes with a cost: your read latency is lower (cache hits), but your write latency is higher (two-phase writes). If your system is extremely write-heavy with few reads, this pattern may add more overhead than value.
Side-by-Side Comparison
| Read-Through | Write-Through | |
|---|---|---|
| Who triggers population | Cache (on miss) | Application (on write) |
| Cache freshness | Eventually fresh (TTL-driven) | Always fresh |
| First-request latency | Slow (cold miss) | N/A |
| Write latency | N/A | Higher (two writes) |
| Application complexity | Low | Low |
| Best for | Read-heavy, infrequent updates | Balanced reads/writes, freshness required |
A Real-World Example
Imagine you're building a gaming leaderboard. Player scores change frequently (write-heavy) and millions of players check rankings constantly (read-heavy).
- Write-through: When a player's score updates, write to both Redis and the database. Redis always has the latest score — no stale leaderboard.
- Read-through: When a new leaderboard segment is requested (e.g., "top players in Brazil"), the cache fetches and stores it automatically. No manual cache warming needed.
Together, they give you a leaderboard that's always current and always fast.
Summary
Read-through delegates cache population to the cache layer — your application just requests data and the cache handles misses. It's ideal for read-heavy scenarios where data changes infrequently.
Write-through ensures the cache and database stay in sync on every write. It's ideal when freshness matters and you can afford slightly higher write latency.
Use them together for the most coherent caching architecture. The tradeoffs to remember: read-through pays a cost on cold misses, write-through pays a cost on every write. Design around those.
How helpful was this content?
Comments
Sign in to join the discussion
Saved on this device only
Sign in to sync progress across devices