Untitled Lesson
Skill Matrix
UNLOCK NODES BY LEARNING NEW TAGS.
Why is retrieving data from Redis significantly faster than retrieving the exact same data from a PostgreSQL database?
💻 Code Challenge | +75 XP
Write the Node.js/Backend code snippet to implement a Node Introduction Redis pipeline. Include the setup and basic execution steps.
You are reviewing a Node Introduction Redis pipeline and the output is incorrect. Reorder the following pipeline stages in the correct logical order to fix the bug: Input Data, Process, Output.
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 //
Caching values with client.set() and never setting a TTL
// Wrong: this key never expires, RAM usage only grows
await client.set('user:1', JSON.stringify(user));
// Correct: expires automatically after 300 seconds
await client.setEx('user:1', 300, JSON.stringify(user));The Solution //
Redis stores everything in RAM, which is finite and expensive. Keys written with a plain SET and no expiration live forever unless explicitly deleted, and on a long-running app this steadily fills memory until Redis starts evicting keys unpredictably (or refuses writes, depending on maxmemory-policy). Always use setEx or an equivalent TTL-bearing call for cache entries.
The Error //
Updating the database but forgetting to invalidate the corresponding Redis cache entry
async function updateUser(id, data) {
await Postgres.query('UPDATE users SET ... WHERE id = $1', [id]);
await redis.del(`user:${id}`); // invalidate the stale cache entry
}The Solution //
The cache-aside pattern only checks Redis on reads — if a write path updates Postgres directly without also deleting or refreshing the matching Redis key, every subsequent read serves stale data until the TTL happens to expire. Always invalidate (or update) the cache key as part of the same write operation that changes the underlying record.