Why caching reduces response latency in NestJS - Visual Breakdown

Concept Flow - Why caching reduces response latency

Client sends request

↓

Check cache for data

↓

Return cached

↓

response fast

↓

Store data in cache

↓

Return response

The system first checks if the requested data is in cache. If yes, it returns it immediately, skipping slower database or API calls, thus reducing response time.

Execution Sample

NestJS

async getUser(id: string) {
  const cached = await this.cacheManager.get(id);
  if (cached) return cached;
  const user = await this.userService.findById(id);
  await this.cacheManager.set(id, user);
  return user;
}

This function tries to get user data from cache first; if missing, it fetches from the database, caches it, then returns.

Execution Table

Step	Action	Cache Check Result	Data Source	Cache Update	Response
1	Receive request for user id '123'	N/A	N/A	N/A	N/A
2	Check cache for '123'	Miss	N/A	N/A	N/A
3	Fetch user from DB	N/A	Database	N/A	N/A
4	Store user data in cache	N/A	N/A	Cache set '123'	N/A
5	Return user data	N/A	N/A	N/A	User data from DB
6	Receive request for user id '123' again	N/A	N/A	N/A	N/A
7	Check cache for '123'	Hit	Cache	N/A	User data from cache
8	Return cached user data	N/A	N/A	N/A	User data from cache

💡 Execution stops after returning user data from cache or DB.

Variable Tracker

Variable	Start	After Step 2	After Step 4	After Step 7	Final
cacheManager.get('123')	undefined	undefined (miss)	user object cached	user object cached (hit)	user object cached
user	undefined	undefined	user object from DB	user object from DB	user object returned

Key Moments - 2 Insights

Why does the function return immediately when cache has data?

Because the cache hit at step 7 means data is ready locally, so no need to wait for slower DB fetch (see execution_table row 7).

What happens when cache misses the data?

The function fetches data from the database (step 3), then stores it in cache (step 4) before returning (step 5), as shown in execution_table rows 3-5.

Visual Quiz - 3 Questions

Look at the execution table, what is the data source at step 3?

A Database

B API

C Cache

D Undefined

💡 Hint

Check the 'Data Source' column at step 3 in the execution_table.

At which step does the cache get updated with new data?

A Step 7

B Step 2

C Step 4

D Step 5

💡 Hint

Look at the 'Cache Update' column in the execution_table.

If the cache always hits, which steps would be skipped?

A Steps 2 and 7

B Steps 3 and 4

C Steps 5 and 8

D Steps 1 and 6

💡 Hint

Refer to execution_table rows where cache miss triggers DB fetch and cache set.

Concept Snapshot

Caching stores data temporarily to serve future requests faster.
Check cache first: if data found, return immediately.
If not found, fetch from DB/API, store in cache, then return.
Reduces response latency by avoiding slow data fetches repeatedly.
Common in NestJS using cacheManager with async get/set methods.

Full Transcript

When a client requests data, the system first checks if the data is in cache. If it is, the cached data is returned immediately, making the response very fast. If the data is not in cache, the system fetches it from the database or an API, then stores it in cache for future requests before returning it. This process reduces response latency by avoiding repeated slow data fetches. In NestJS, this is done using the cacheManager's get and set methods asynchronously.

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