Message patterns (request-response) in NestJS - Performance & Optimization

Performance: Message patterns (request-response)

MEDIUM IMPACT

This affects the responsiveness and throughput of backend services handling request-response messaging patterns.

Handling request-response messages in NestJS microservices

NestJS

import { Controller } from '@nestjs/common';
import { MessagePattern } from '@nestjs/microservices';

@Controller()
export class AppController {
  @MessagePattern('sum')
  async handleSum(data: number[]) {
    // offload heavy processing asynchronously
    return await new Promise((resolve) => {
      setImmediate(() => {
        let result = 0;
        for (const num of data) {
          for (let j = 0; j < 1000000; j++) {
            result += num;
          }
        }
        resolve(result);
      });
    });
  }
}

Offloading heavy computation asynchronously prevents blocking the event loop, allowing other requests to be processed.

📈 Performance GainReduces event loop blocking, improving INP and overall throughput.

Handling request-response messages in NestJS microservices

NestJS

import { Controller } from '@nestjs/common';
import { MessagePattern } from '@nestjs/microservices';

@Controller()
export class AppController {
  @MessagePattern('sum')
  async handleSum(data: number[]) {
    // heavy synchronous processing
    let result = 0;
    for (let i = 0; i < data.length; i++) {
      for (let j = 0; j < 1000000; j++) {
        result += data[i];
      }
    }
    return result;
  }
}

Heavy synchronous processing blocks the event loop, delaying responses and reducing throughput.

📉 Performance CostBlocks event loop for hundreds of milliseconds per request, increasing INP and response time.

Performance Comparison

Pattern	Event Loop Blocking	Response Delay	Throughput Impact	Verdict
Synchronous heavy processing	High (blocks event loop)	High (delays response)	Low (reduces throughput)	[X] Bad
Asynchronous offloading	Low (non-blocking)	Low (fast response)	High (better throughput)	[OK] Good

Rendering Pipeline

In NestJS request-response message patterns, the server receives a message, processes it, and sends a response. Blocking operations delay the event loop, causing slower response times and poor interaction responsiveness.

→Message Reception

→Processing

→Response Sending

⚠️ BottleneckProcessing stage when synchronous heavy tasks block the event loop

Core Web Vital Affected

INP

This affects the responsiveness and throughput of backend services handling request-response messaging patterns.

Optimization Tips

1Avoid synchronous heavy processing in message handlers to prevent event loop blocking.

2Use asynchronous or offloaded tasks for CPU-intensive work in NestJS microservices.

3Monitor event loop blocking in performance tools to ensure responsive request handling.

Performance Quiz - 3 Questions

What is the main performance issue with synchronous heavy processing in NestJS message handlers?

A It increases bundle size significantly

B It causes layout shifts in the browser

C It blocks the event loop, delaying other requests

D It reduces network bandwidth

DevTools: Performance

How to check: Record a performance profile while sending messages to the NestJS microservice. Look for long tasks blocking the event loop.

What to look for: Long tasks in the main thread timeline indicate blocking synchronous processing causing delayed responses.

Practice

1. What is the main purpose of the @MessagePattern decorator in NestJS?

easy

A. To define HTTP routes in a controller

B. To listen for specific message types and handle incoming messages

C. To send messages to other microservices

D. To configure database connections

Solution

1. Step 1: Understand the role of @MessagePattern

   This decorator is used to mark a method that listens for messages matching a specific pattern.

2. Step 2: Differentiate from other decorators

   Unlike HTTP route decorators, @MessagePattern is for message-based communication, not HTTP or database setup.

3. Final Answer:

   To listen for specific message types and handle incoming messages -> Option B

4. Quick Check:

   @MessagePattern listens for messages [OK]

Hint: Remember: @MessagePattern listens, not sends [OK]

Common Mistakes:

• Confusing @MessagePattern with HTTP route decorators
• Thinking it sends messages instead of listening
• Assuming it configures databases

2. Which of the following is the correct way to define a message handler for the pattern 'sum_numbers' in NestJS?

easy

A. @Subscribe('sum_numbers')
handleSum(data: number[]) { return data.reduce((a, b) => a + b); }

B. @Get('sum_numbers')
handleSum(data: number[]) { return data.reduce((a, b) => a + b); }

C. @Post('sum_numbers')
handleSum(data: number[]) { return data.reduce((a, b) => a + b); }

D. @MessagePattern('sum_numbers')
handleSum(data: number[]) { return data.reduce((a, b) => a + b); }

Solution

1. Step 1: Identify the correct decorator for message patterns

   @MessagePattern is the correct decorator to listen for messages, not @Get, @Post, or @Subscribe.

2. Step 2: Confirm the syntax

   The pattern string 'sum_numbers' is correctly passed as an argument to @MessagePattern, and the handler method processes the data.

3. Final Answer:

   @MessagePattern('sum_numbers') handleSum(data: number[]) { return data.reduce((a, b) => a + b); } -> Option D

4. Quick Check:

   Use @MessagePattern('pattern') for message handlers [OK]

Hint: Use @MessagePattern for message handlers, not HTTP decorators [OK]

Common Mistakes:

• Using HTTP decorators like @Get or @Post for message patterns
• Using non-existent decorators like @Subscribe
• Forgetting to pass the pattern string to @MessagePattern

3. Given the following NestJS message handler, what will be the response when the message pattern 'multiply' is sent with data [2, 3]?

@MessagePattern('multiply')
handleMultiply(data: number[]) {
  return data[0] * data[1];
}

medium

A. 6

B. undefined

C. [2, 3]

D. 5

Solution

1. Step 1: Understand the handler logic

   The handler receives an array of numbers and returns the product of the first two elements: data[0] * data[1].

2. Step 2: Calculate the product for input [2, 3]

   2 * 3 equals 6, so the response will be 6.

3. Final Answer:

   6 -> Option A

4. Quick Check:

   2 multiplied by 3 equals 6 [OK]

Hint: Multiply first two array elements for 'multiply' pattern [OK]

Common Mistakes:

• Adding instead of multiplying the numbers
• Returning the input array instead of the product
• Assuming undefined because of missing return

4. Identify the error in the following NestJS message handler code:

@MessagePattern('greet')
async handleGreet(name: string) {
  console.log('Greeting:', name);
}

medium

A. The @MessagePattern decorator is missing the pattern string

B. The method should not be async

C. The handler does not return a response to the sender

D. The parameter type should be an object, not a string

Solution

1. Step 1: Check the handler's return behavior

   The handler logs the name but does not return any value, so the sender gets no response.

2. Step 2: Verify decorator and parameter correctness

   The decorator has the pattern string 'greet', and the parameter type string is acceptable for simple messages.

3. Final Answer:

   The handler does not return a response to the sender -> Option C

4. Quick Check:

   Handlers must return a response [OK]

Hint: Always return a value in message handlers [OK]

Common Mistakes:

• Not returning a response causes sender to wait indefinitely
• Confusing async usage with missing return
• Assuming parameter type must be object always

5. You want to create a NestJS microservice that listens for a message pattern 'calculate' and returns the sum of two numbers sent in an object like { a: 5, b: 7 }. Which of the following handler implementations correctly achieves this?

hard

A. @MessagePattern('calculate')
handleCalculate(data: { a: number; b: number }) {
return data.a + data.b;
}

B. @MessagePattern('calculate')
handleCalculate(a: number, b: number) {
return a + b;
}

C. @MessagePattern('calculate')
handleCalculate(data: number[]) {
return data[0] + data[1];
}

D. @MessagePattern('calculate')
handleCalculate(data: string) {
return parseInt(data);
}

Solution

1. Step 1: Match the expected input structure

   The message sends an object with properties a and b, so the handler must accept an object with those properties.

2. Step 2: Verify the handler logic

   The handler correctly accesses data.a and data.b and returns their sum.

3. Step 3: Check other options for correctness

   @MessagePattern('calculate') handleCalculate(a: number, b: number) { return a + b; } expects two separate parameters, which does not match the single object sent. @MessagePattern('calculate') handleCalculate(data: number[]) { return data[0] + data[1]; } expects an array, and @MessagePattern('calculate') handleCalculate(data: string) { return parseInt(data); } expects a string, both incorrect.

4. Final Answer:

   @MessagePattern('calculate') handleCalculate(data: { a: number; b: number }) { return data.a + data.b; } -> Option A

5. Quick Check:

   Match input shape and sum properties [OK]

Hint: Match handler parameter to message data shape exactly [OK]

Common Mistakes:

• Using multiple parameters instead of one object
• Expecting array when object is sent
• Parsing string instead of object