Untitled Lesson
Skill Matrix
UNLOCK NODES BY LEARNING NEW TAGS.
What is the primary tradeoff write-through caching makes compared to cache-aside, in exchange for eliminating the "missed invalidation" staleness risk?
💻 Code Challenge | +75 XP
Implement a write-through updateUser function that updates the database and cache together, with proper handling of a cache-write failure by invalidating (not leaving stale) the entry, falling back to standard cache-aside logic for reads.
A team using write-through caching found that data updated via a direct database migration script was still served as stale from the cache for hours afterward. Reorder the steps to understand and address this gap.
Task: Reorder the blocks in logical sequence to solve the problem.
A.D.A. Interface
Adaptive Didactic Assistant
Pascual Vila
Frontend Instructor // Code Syllabus
The Error //
Leaving a cache entry in a stale state after a cache write fails, following a successful database write
// Wrong: a failed cache write leaves the OLD, now-stale value in place
await db.users.update(userId, data);
await redis.set(`user:${userId}`, JSON.stringify(data)); // if this throws, old value remains!
// Correct: invalidate on failure, don't leave stale data
try { await redis.set(`user:${userId}`, JSON.stringify(data)); }
catch { await redis.del(`user:${userId}`); }The Solution //
If the database update succeeds but the subsequent cache update fails (a transient error), simply leaving the old cached value in place means it is now stale and incorrect — invalidating (deleting) the cache entry on a write-through failure, rather than leaving stale data, falls back safely to standard cache-aside behavior for that specific entry until it's next read and repopulated.
The Error //
Assuming write-through eliminates the need for a TTL on cached entries
// Insufficient alone: no protection against writes bypassing the app entirely
await redis.set(key, value); // no expiration
// Correct: a TTL remains a valuable safety net regardless
await redis.set(key, value, "EX", 3600);The Solution //
Write-through only guarantees freshness for writes that go through the application's own write-through logic — a write to the underlying database from an entirely separate path (a migration script, another service) bypasses this logic and can leave the cache stale indefinitely without a TTL as a safety net.