Why caching reduces response latency in NestJS - See It in Action

Why caching reduces response latency

📖 Scenario: You are building a simple NestJS service that fetches user data. To make the service faster, you want to add caching so repeated requests for the same user do not take long.

🎯 Goal: Build a NestJS service that caches user data in memory to reduce response latency on repeated requests.

📋 What You'll Learn

Create a simple user data object

Add a cache variable to store fetched users

Implement a method to check cache before fetching user data

Return cached data if available, otherwise fetch and cache it

💡 Why This Matters

🌍 Real World

Caching is used in web services to speed up responses by storing data temporarily so repeated requests are faster.

💼 Career

Understanding caching helps backend developers optimize APIs and improve user experience by reducing wait times.

1

Create initial user data object

Create a constant called users that is an object with these exact entries: 1: { id: 1, name: 'Alice' }, 2: { id: 2, name: 'Bob' }, 3: { id: 3, name: 'Charlie' }.

NestJS

// Create the users object with three users
// Your code here

Hint

Use a constant object named users with keys 1, 2, and 3 each holding an object with id and name.

2

Add cache storage variable

Add a variable called cache and set it to an empty object {} to store cached user data.

NestJS

const users = {
  1: { id: 1, name: 'Alice' },
  2: { id: 2, name: 'Bob' },
  3: { id: 3, name: 'Charlie' }
};

// Create cache object to store fetched users
// Your code here

Hint

Use const cache = {} to create an empty object for caching.

3

Implement caching logic in getUser function

Write a function called getUser that takes id as a parameter. Inside, first check if cache[id] exists. If yes, return cache[id]. Otherwise, get the user from users[id], store it in cache[id], then return it.

NestJS

const users = {
  1: { id: 1, name: 'Alice' },
  2: { id: 2, name: 'Bob' },
  3: { id: 3, name: 'Charlie' }
};

const cache = {};

// Create getUser function with caching logic
// Your code here

Hint

Use an if statement to check cache[id]. Return cached data if found. Otherwise, get from users, cache it, then return.

4

Export getUser function for use in NestJS service

Add export before the function getUser declaration to make it available outside this module.

NestJS

const users = {
  1: { id: 1, name: 'Alice' },
  2: { id: 2, name: 'Bob' },
  3: { id: 3, name: 'Charlie' }
};

const cache = {};

// Export getUser function
// Your code here

Hint

Add export before the function to share it with other files.

Practice

1. Why does caching reduce response latency in a NestJS application?

easy

A. Because it stores frequently requested data temporarily to avoid repeated slow operations

B. Because it increases the size of the database

C. Because it disables network requests completely

D. Because it compresses the response data before sending

Solution

1. Step 1: Understand what caching does

   Caching temporarily stores data that is requested often, so the system doesn't have to fetch it repeatedly from slow sources like databases or APIs.

2. Step 2: Connect caching to response time

   By avoiding repeated slow operations, caching reduces the time the app waits before sending a response, thus lowering latency.

3. Final Answer:

   Because it stores frequently requested data temporarily to avoid repeated slow operations -> Option A

4. Quick Check:

   Caching stores data to speed up responses = A [OK]

Hint: Caching saves repeated data fetch time to speed responses [OK]

Common Mistakes:

• Thinking caching increases database size
• Believing caching disables network requests
• Confusing caching with data compression

2. Which of the following is the correct way to import caching in a NestJS module?

easy

A. import { CacheModule } from '@nestjs/common';

B. import { CacheInterceptor } from '@nestjs/core';

C. import { CacheModule } from '@nestjs/cache';

D. import { CacheService } from '@nestjs/common';

Solution

1. Step 1: Identify the correct NestJS package for CacheModule

   CacheModule is part of the '@nestjs/common' package, so it should be imported from there.

2. Step 2: Verify other options

   CacheInterceptor is from '@nestjs/common', not '@nestjs/core'; '@nestjs/cache' and CacheService do not exist as valid imports.

3. Final Answer:

   import { CacheModule } from '@nestjs/common'; -> Option A

4. Quick Check:

   CacheModule import is from '@nestjs/common' = D [OK]

Hint: CacheModule always imports from '@nestjs/common' [OK]

Common Mistakes:

• Importing CacheModule from wrong package
• Confusing CacheInterceptor import location
• Using non-existent CacheService import

3. Given this NestJS controller snippet using caching:

  @UseInterceptors(CacheInterceptor)
  @Get('data')
  async getData() {
    console.log('Fetching data...');
    return { value: 42 };
  }

What will happen on the second request to /data?

medium

A. The console logs 'Fetching data...' again and returns { value: 42 }

B. The request fails with a cache error

C. The console does not log anything and returns cached { value: 42 }

D. The console logs twice and returns { value: 42 } twice

Solution

1. Step 1: Understand CacheInterceptor behavior

   CacheInterceptor caches the response of the first request and returns it directly on subsequent requests without calling the method again.

2. Step 2: Predict console output on second request

   Since the method is not called again, 'Fetching data...' is not logged on the second request, but the cached response is returned.

3. Final Answer:

   The console does not log anything and returns cached { value: 42 } -> Option C

4. Quick Check:

   CacheInterceptor returns cached data without method call = C [OK]

Hint: CacheInterceptor skips method call on cached requests [OK]

Common Mistakes:

• Assuming method runs every time
• Expecting cache errors on normal use
• Thinking console logs twice per request

4. This NestJS code tries to enable caching but has an error:

  @Module({
    imports: [CacheModule.register()],
    controllers: [AppController],
    providers: [AppService, CacheInterceptor],
  })
  export class AppModule {}

What is the main problem here?

medium

A. CacheModule.register() requires a cache store option

B. CacheInterceptor should be provided using APP_INTERCEPTOR token, not directly

C. CacheInterceptor cannot be used with AppService

D. CacheModule must be imported from '@nestjs/core'

Solution

1. Step 1: Check how to provide CacheInterceptor globally

   CacheInterceptor must be provided using the special token APP_INTERCEPTOR to work as a global interceptor.

2. Step 2: Identify the error in providers array

   Providing CacheInterceptor directly in providers does not activate it globally; it needs to be wrapped with APP_INTERCEPTOR.

3. Final Answer:

   CacheInterceptor should be provided using APP_INTERCEPTOR token, not directly -> Option B

4. Quick Check:

   Use APP_INTERCEPTOR token to provide CacheInterceptor = B [OK]

Hint: Use APP_INTERCEPTOR token to enable CacheInterceptor globally [OK]

Common Mistakes:

• Providing CacheInterceptor directly in providers
• Thinking CacheModule always needs cache store option
• Importing CacheModule from wrong package

5. You want to cache user profile data in NestJS but only for users with a premium subscription. Which approach best reduces response latency without caching non-premium users?

hard

A. Use CacheModule with a global TTL that applies to all users equally

B. Cache all user profiles regardless of subscription to simplify caching

C. Disable caching and fetch all profiles fresh every time

D. Use CacheInterceptor with a custom cache key that includes user type and skip caching for non-premium users

Solution

1. Step 1: Understand selective caching needs

   To cache only premium users, caching logic must distinguish user types and avoid caching non-premium data.

2. Step 2: Apply custom cache key and conditional caching

   Using CacheInterceptor with a custom cache key including user type allows caching premium users separately and skipping others.

3. Step 3: Evaluate other options

   Caching all users wastes resources; disabling caching loses latency benefits; global TTL applies to all users, not selective.

4. Final Answer:

   Use CacheInterceptor with a custom cache key that includes user type and skip caching for non-premium users -> Option D

5. Quick Check:

   Selective caching with custom keys reduces latency best = A [OK]

Hint: Customize cache keys to cache only needed data [OK]

Common Mistakes:

• Caching all data without filtering
• Disabling caching completely
• Using global TTL without user distinction