Read-Through and Write-Through Caching with Redis

Cache-aside puts the caching logic in your application. Read-through and write-through move it into the cache layer itself, so the application talks to the cache as if it were the database and the cache handles loading from and writing to the backing store. The difference sounds subtle, but it changes who owns the logic, how consistent the cache stays, and where the complexity lives. Knowing all three patterns lets you pick the right consistency-versus-complexity tradeoff per use case.

This is part 10 of the Redis Masterclass, following cache-aside.

Read-through: the cache loads on a miss

In read-through, the application always reads from the cache, and the cache is responsible for fetching from the database on a miss. Where cache-aside has the application do the "load from DB and populate" step, read-through hides that behind the cache layer:

// application code is simple: just read from the cache
const user = await cache.get(`user:${id}`);
// the cache layer, on a miss, loads from the DB, stores it, and returns it

The behavior is nearly identical to cache-aside from the outside: lazy loading, TTLs, misses populate the cache. The difference is where the logic lives. Read-through requires a cache that can call your database (a provider, a library, or a wrapper you build), so the loading logic is centralized in one place instead of repeated at every call site.

The advantage is consistency of implementation: every read goes through the same loading path, so you can't forget to populate the cache in one code path. The cost is that you need that cache-with-loader layer. In practice, many teams get read-through's benefit by wrapping cache-aside in a single shared function, which is the same idea without special infrastructure.

Write-through: the cache writes to the database

Write-through pairs with read-through on the write side. The application writes to the cache, and the cache synchronously writes to the database before acknowledging:

// application writes to the cache; the cache writes through to the DB
await cache.set(`user:${id}`, updatedUser);
// internally: cache updates Redis AND writes to the database, then returns

Both the cache and the database are updated in one operation, so the cache is always consistent with the database (no stale entries from a forgotten invalidation). Every write keeps them in lockstep.

The tradeoff is write latency. Because the write goes to both the cache and the database synchronously, a write is as slow as the database write plus the cache write. You've added the cache to the write path, so writes don't get faster (reads do). And you're caching data on write whether or not it'll ever be read, which can fill the cache with cold data.

Read-through plus write-through: consistent but not faster to write

Used together, read-through and write-through give a cache that stays consistent with the database automatically: reads populate on miss, writes update both stores. The application treats the cache as its interface to data, and the cache keeps itself in sync. This is appealing when you want strong cache consistency without scattering invalidation logic through the app.

The honest limitations: writes aren't faster (they hit both stores), the cache holds data that may never be read (written on every write), and you need the cache layer to support the pattern. It shines for read-heavy data where consistency matters and you want the caching logic centralized, and it's overkill for simple caching where cache-aside's delete-on-write is enough.

Choosing between the patterns

Here's how the three compare so far:

• Cache-aside: application manages the cache; load on miss, invalidate on write. Simplest, most common, degrades gracefully, but the logic is spread across the app and can be applied inconsistently.
• Read-through: the cache loads on miss, centralizing read logic. Same behavior as cache-aside, cleaner if you have a cache layer that supports it.
• Write-through: the cache writes synchronously to the database, keeping cache and database consistent, at the cost of write latency and caching unread data.

A common, pragmatic setup is cache-aside reads with write-through-style consistency achieved by updating the database and invalidating the cache in one well-tested shared function, getting most of the benefit without a special cache provider.

Where consistency comes from

The real theme across these patterns is where cache consistency is enforced. Cache-aside relies on the application remembering to invalidate. Write-through enforces it structurally, because every write updates both stores. If forgotten invalidations are causing stale-cache bugs, moving to a write-through-style pattern (or centralizing the invalidation) fixes them by making consistency automatic rather than a thing developers must remember.

Read-through and write-through trade the application's control for the cache's automatic consistency. They're the right call when you want centralized, hard-to-forget cache logic and can tolerate write-through's latency. When you want simplicity and graceful degradation, cache-aside remains the workhorse. The next patterns push further: write-behind trades consistency for write speed, and refresh-ahead trades work for avoiding misses entirely.