What is the difference between write-through, write-behind, and cache-aside patterns?
Compare cache-aside, write-through, and write-behind caching in Redis: how each keeps cache and database in sync, plus latency and consistency trade-offs.
Expected Interview Answer
These are three strategies for keeping a cache and a database consistent. In cache-aside the application reads from cache and loads from the database on a miss; in write-through the application writes to the cache and the cache synchronously writes to the database; in write-behind the cache writes to the database asynchronously later.
Cache-aside (lazy loading) puts the application in control: on a read miss it fetches from the database, populates the cache, and returns, while writes usually update the database and invalidate the cache. Write-through keeps cache and database in lockstep on every write, giving strong consistency at the cost of higher write latency. Write-behind (write-back) acknowledges the write immediately and flushes to the database in batches, giving the lowest write latency but risking data loss if the cache fails before flushing. The right choice depends on read/write ratio, consistency needs, and tolerance for data loss.
- Cache-aside is simple and resilient to cache failure
- Write-through keeps cache and database strongly consistent
- Write-behind delivers the lowest write latency
- Each maps to a different read/write and durability profile
- Understanding all three lets you match pattern to workload
AI Mentor Explanation
Cache-aside is a scorer who checks his notebook first and only asks the umpire when a figure is missing, then jots it down. Write-through is a scorer who records every run in both his book and the official register at the same moment. Write-behind is one who scribbles quickly on a notepad and copies it all into the official register at the innings break, fast but risky if the notepad is lost.
Step-by-Step Explanation
Step 1
Cache-aside read
Check the cache first; on a miss, read from the database, store the result in the cache, then return it.
Step 2
Cache-aside write
Write to the database and invalidate or update the cache entry so the next read reloads fresh data.
Step 3
Write-through
The application writes to the cache, and the cache synchronously persists to the database before acknowledging.
Step 4
Write-behind
The cache acknowledges the write immediately and queues it, flushing to the database asynchronously in batches.
Step 5
Pick by workload
Match the pattern to read/write ratio, consistency requirements, and how much data loss you can tolerate.
What Interviewer Expects
- Clear distinction between who writes to the database and when
- Understanding that cache-aside puts the app in control on misses
- Awareness that write-through trades latency for consistency
- Knowledge that write-behind risks data loss for speed
- Ability to pick a pattern for a given workload
Common Mistakes
- Confusing write-through with write-behind
- Claiming cache-aside guarantees strong consistency
- Ignoring the data-loss risk of write-behind on cache failure
- Forgetting to invalidate the cache on writes in cache-aside
- Assuming one pattern is always best regardless of workload
Best Answer (HR Friendly)
“These are three ways to keep a fast cache and a slower database in agreement. Cache-aside loads data into the cache only when it is first needed, write-through updates both at the same time for safety, and write-behind updates the cache immediately and the database a little later for speed.”
Code Example
// Cache-aside: application manages the cache
async function readUser(redis, db, id) {
const cached = await redis.get(`user:${id}`);
if (cached) return JSON.parse(cached); // cache hit
const user = await db.getUser(id); // miss -> load from DB
await redis.set(`user:${id}`, JSON.stringify(user), 'PX', 60000);
return user;
}
async function updateUser(redis, db, id, data) {
await db.updateUser(id, data); // write to DB
await redis.del(`user:${id}`); // invalidate cache
}// Write-through: cache write persists to DB before returning
async function writeThrough(cache, db, key, value) {
await cache.set(key, value);
await db.save(key, value); // synchronous -> strong consistency
}
// Write-behind: acknowledge fast, flush later in a batch
async function writeBehind(cache, queue, key, value) {
await cache.set(key, value);
queue.push({ key, value }); // flushed to DB asynchronously
}Follow-up Questions
- Which pattern would you choose for a write-heavy analytics workload?
- How does write-behind handle a cache crash before flushing?
- Why can cache-aside briefly serve stale data after a write?
- How do you avoid the dual-write inconsistency in write-through?
- Where does read-through fit relative to these patterns?
MCQ Practice
1. In cache-aside, who loads data into the cache on a miss?
Cache-aside (lazy loading) has the application read from the database on a miss and then populate the cache itself.
2. Which pattern offers the lowest write latency but the highest data-loss risk?
Write-behind acknowledges immediately and flushes to the database later, so a cache failure before flush can lose data.
3. What is the main trade-off of write-through?
Write-through writes synchronously to both cache and database, keeping them consistent at the cost of slower writes.
Flash Cards
Cache-aside in one line? — App reads cache first, loads from DB on a miss and populates the cache; writes update the DB and invalidate the cache.
Write-through in one line? — App writes to the cache, which synchronously persists to the DB — strong consistency, higher write latency.
Write-behind in one line? — Cache acknowledges the write immediately and flushes to the DB asynchronously — lowest latency, data-loss risk.
Which pattern survives cache failure best? — Cache-aside, because the database remains the source of truth and the app can always fall back to it.
Biggest risk of write-behind? — Losing buffered writes if the cache crashes before the asynchronous flush completes.
Continue Learning
Related Interview Questions
What is cache invalidation and what strategies work with Redis?
medium
What is Redis and what makes it different from a traditional relational database?
easy
What is a cache stampede (thundering herd) and how do you prevent it in Redis?
hard
How does Redis client-side caching with CLIENT TRACKING work, and when is it worth it?
hard