Redis integration for distributed cache in Express - Step-by-Step Execution

Concept Flow - Redis integration for distributed cache

Start Express Server

↓

Initialize Redis Client

↓

Receive HTTP Request

↓

Check Redis Cache for Key

↓

Return Cached

↓

Send Response

↓

Send Response

↓

End

The server starts, connects to Redis, then on each request it checks cache first. If data is cached, it returns it. Otherwise, it fetches fresh data, caches it, then returns it.

Execution Sample

Express

import express from 'express';
import { createClient } from 'redis';

const app = express();
const redisClient = createClient();

redisClient.connect();

app.get('/data', async (req, res) => {
  const cacheKey = 'myData';
  const cached = await redisClient.get(cacheKey);
  if (cached) return res.send(JSON.parse(cached));
  const freshData = { value: 'Hello from DB' };
  await redisClient.set(cacheKey, JSON.stringify(freshData));
  res.send(freshData);
});

app.listen(3000);

This code sets up an Express server that uses Redis to cache data for the '/data' route, returning cached data if available or fetching fresh data and caching it.

Execution Table

Step	Action	Redis Cache Check	Cache Hit?	Data Source	Cache Update	Response Sent
1	Start server and connect Redis	N/A	N/A	N/A	N/A	N/A
2	Receive GET /data request	Check key 'myData'	No	Fetch from DB	Set key 'myData' with fresh data	Send fresh data
3	Receive GET /data request again	Check key 'myData'	Yes	Use cached data	No update	Send cached data
4	Receive GET /data request third time	Check key 'myData'	Yes	Use cached data	No update	Send cached data
5	Stop server	N/A	N/A	N/A	N/A	N/A

💡 Server stops or no more requests; Redis connection closed.

Variable Tracker

Variable	Start	After 1	After 2	After 3	Final
cacheKey	'myData'	'myData'	'myData'	'myData'	'myData'
cached	null	null	'{"value":"Hello from DB"}'	'{"value":"Hello from DB"}'	'{"value":"Hello from DB"}'
freshData	undefined	{"value":"Hello from DB"}	{"value":"Hello from DB"}	{"value":"Hello from DB"}	{"value":"Hello from DB"}

Key Moments - 3 Insights

Why does the server fetch fresh data only on the first request?

Because at step 2 in the execution_table, Redis cache is empty (cache hit is No), so it fetches fresh data and stores it. Later requests find cached data (cache hit Yes) and skip fetching.

What happens if Redis is not connected when the request comes in?

The Redis client would fail to get or set data, so the server would fetch fresh data every time, acting like no cache. This is not shown in the table but is important to handle in real code.

Why do we JSON.stringify and JSON.parse data with Redis?

Redis stores strings, so objects must be converted to strings before storing and parsed back after retrieving, as shown in the cached variable values in variable_tracker.

Visual Quiz - 3 Questions

Look at the execution_table at step 3, what is the source of data sent in the response?

A Fresh data fetched from the database

B No data is sent

C Cached data from Redis

D An error message

💡 Hint

Check the 'Cache Hit?' and 'Data Source' columns at step 3 in execution_table

At which step does the Redis cache get updated with fresh data?

A Step 1

B Step 2

C Step 3

D Step 4

💡 Hint

Look at the 'Cache Update' column in execution_table to find when 'Set key' happens

If the cacheKey changed to 'newData', how would the variable_tracker change after the first request?

A cacheKey would be 'newData' instead of 'myData'

B cached would be null after first request

C freshData would be undefined

D No change in variable_tracker

💡 Hint

Check the 'cacheKey' row values in variable_tracker

Concept Snapshot

Redis integration for distributed cache in Express:
- Initialize Redis client and connect before server listens
- On request, check Redis cache for key
- If cache hit, return cached data
- If cache miss, fetch fresh data, store in Redis, then return
- Use JSON.stringify/parse to store objects
- Improves performance by reducing DB calls

Full Transcript

This visual execution shows how an Express server integrates Redis for distributed caching. The server starts and connects to Redis. When a GET request to '/data' arrives, it checks Redis for cached data under the key 'myData'. If no cached data is found, it fetches fresh data from the database, stores it in Redis, and sends it in the response. Subsequent requests find cached data and return it directly, skipping the database. Variables like cacheKey, cached, and freshData change as requests are processed. Key beginner confusions include why fresh data is fetched only once, the importance of Redis connection, and why JSON conversion is needed. The quizzes test understanding of cache hits, cache updates, and variable changes. This pattern helps speed up responses by avoiding repeated database queries.

Practice

1. What is the main benefit of integrating Redis as a distributed cache in an Express application?

easy

A. It speeds up data access by storing shared data in memory across servers.

B. It replaces the need for a database entirely.

C. It automatically scales the Express server instances.

D. It provides a user interface for managing Express routes.

Solution

1. Step 1: Understand Redis role in caching

   Redis stores data in memory, making data access very fast compared to disk-based storage.

2. Step 2: Recognize distributed cache benefit

   Redis can be shared across multiple servers, so all Express instances access the same cached data, improving speed and consistency.

3. Final Answer:

   It speeds up data access by storing shared data in memory across servers. -> Option A

4. Quick Check:

   Redis cache = fast shared data [OK]

Hint: Redis caches shared data in memory for speed [OK]

Common Mistakes:

• Thinking Redis replaces the database
• Confusing Redis with server scaling tool
• Assuming Redis manages Express routes

2. Which of the following is the correct way to create a Redis client in an Express app using the latest redis package?

easy

A. const client = new Redis(); client.start();

B. const client = redis.createClient(); client.connect();

C. const client = redis.connectClient();

D. const client = redis.create(); client.open();

Solution

1. Step 1: Recall redis package usage

   The modern redis package uses createClient() to create a client instance.

2. Step 2: Connect the client

   After creating, you must call client.connect() to establish connection asynchronously.

3. Final Answer:

   const client = redis.createClient(); client.connect(); -> Option B

4. Quick Check:

   createClient + connect = correct syntax [OK]

Hint: Use createClient() then connect() to start Redis client [OK]

Common Mistakes:

• Using non-existent methods like start() or open()
• Calling connectClient() which does not exist
• Instantiating Redis with new Redis() incorrectly

3. Given this Express route using Redis cache:

app.get('/data', async (req, res) => {
  const cacheKey = 'myData';
  const cached = await client.get(cacheKey);
  if (cached) return res.send(JSON.parse(cached));
  const data = { value: 42 };
  await client.set(cacheKey, JSON.stringify(data), { EX: 10 });
  res.send(data);
});

What happens when you call /data twice within 10 seconds?

medium

A. The first call stores data in cache, second call returns cached data.

B. The first call fetches from cache, second call fetches fresh data.

C. Both calls fetch fresh data and store it in cache.

D. Both calls return cached data without storing anything.

Solution

1. Step 1: Analyze first call behavior

   On first call, cache is empty, so data is created and stored with 10 seconds expiration.

2. Step 2: Analyze second call within 10 seconds

   Second call finds cached data and returns it directly without recreating or resetting cache.

3. Final Answer:

   The first call stores data in cache, second call returns cached data. -> Option A

4. Quick Check:

   Cache empty first, then hit cache [OK]

Hint: First call caches, second call uses cache within expiry [OK]

Common Mistakes:

• Assuming cache is refreshed on every call
• Thinking cache is never used
• Ignoring expiration time effect

4. Consider this Express code snippet using Redis:

app.get('/count', async (req, res) => {
  const count = await client.get('count');
  const newCount = count + 1;
  await client.set('count', newCount);
  res.send({ count: newCount });
});

What issue will occur when this route is called?

medium

A. SyntaxError due to incorrect async function syntax.

B. ReferenceError because client is not defined.

C. count is a string from Redis, so count + 1 performs string concatenation instead of numeric addition.

D. No error; the count increments correctly.

Solution

1. Step 1: Identify data type of count

   Redis stores values as strings, so count is a string when retrieved (null on first call).

2. Step 2: Analyze addition operation

   Adding number 1 to a string (after first call) results in string concatenation (e.g., "1" + 1 = "11").

3. Step 3: Predict issue

   This causes incorrect count values like 1, "11", "111", etc., instead of proper increments 1, 2, 3.

4. Final Answer:

   count is a string from Redis, so count + 1 performs string concatenation instead of numeric addition. -> Option C

5. Quick Check:

   String + number without conversion = concatenation [OK]

Hint: Convert Redis string to number before adding [OK]

Common Mistakes:

• Assuming Redis returns numbers directly
• Ignoring async/await correctness
• Thinking no error occurs

5. You want to cache user profile data in Redis with a 5-minute expiration in an Express app. Which code snippet correctly sets the cache with expiration and handles errors properly?

hard

A. client.set('user:123', JSON.stringify(profile)); setTimeout(() => client.del('user:123'), 300000);

B. client.set('user:123', JSON.stringify(profile), 300);
console.log('Cache set');

C. await client.set('user:123', profile, { expire: 300 });

D. try {
await client.set('user:123', JSON.stringify(profile), { EX: 300 });
} catch (err) {
console.error('Cache error:', err);
}

Solution

1. Step 1: Use correct Redis set syntax with expiration

   The redis client set method accepts options with EX for expiration in seconds, so { EX: 300 } is correct.

2. Step 2: Handle errors with try-catch

   Since set is async, wrapping in try-catch ensures errors are caught and logged properly.

3. Step 3: Check other options for mistakes

   client.set('user:123', JSON.stringify(profile), 300); console.log('Cache set'); misses async/await and uses wrong expiration argument; C uses wrong option key; D manually deletes cache but is less efficient.

4. Final Answer:

   try { await client.set('user:123', JSON.stringify(profile), { EX: 300 }); } catch (err) { console.error('Cache error:', err); } -> Option D

5. Quick Check:

   set with EX + try-catch = correct [OK]

Hint: Use { EX: seconds } option and try-catch for errors [OK]

Common Mistakes:

• Passing expiration as a separate argument
• Not stringifying objects before caching
• Ignoring async error handling