Untitled Lesson
Skill Matrix
UNLOCK NODES BY LEARNING NEW TAGS.
What problem does an in-process cache (a plain in-memory Map within a single Node.js process) fail to solve for a horizontally-scaled application running multiple replicas?
💻 Code Challenge | +75 XP
Implement a two-tier caching getCached function combining a fast in-process local cache with a shared Redis distributed cache, along with a Pub/Sub-based invalidate function that clears the key both centrally and across every replica's local cache.
A team using a plain in-memory cache within each of their 5 application replicas noticed users occasionally saw inconsistent data depending on which replica happened to handle their request. Reorder the steps to fix this using a distributed cache.
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 //
Using a plain in-process (in-memory) cache in a horizontally-scaled application running multiple replicas
// Wrong: isolated per replica, causes cross-replica inconsistency
const cache = new Map(); // exists ONLY in this one process
// Correct: shared, consistent across every replica
const cache = new Redis({ host: "shared-redis-host" });The Solution //
An in-process cache exists only within a single Node.js process's own memory — with multiple replicas, each maintains its own separate, inconsistent cache, meaning a cache update handled by one replica has no way to be reflected in any other replica's cache, causing genuine data inconsistency depending on which replica happens to serve a given request.
The Error //
Implementing a two-tier caching strategy without a proper cross-replica invalidation mechanism
// Insufficient: only clears the shared tier, local caches remain stale
await redis.del(key);
// Correct: also tells every replica to clear its own local tier
await redis.del(key);
await redis.publish("cache-invalidation", key);The Solution //
Invalidating a key in the shared distributed cache tier doesn't automatically clear that same key from every replica's separate, local in-process cache tier — without an explicit coordination mechanism (like a Pub/Sub invalidation message), stale data can persist in local caches even after the shared tier has been correctly updated.