Why microservices scale independently in NestJS

Introduction

Microservices let parts of an app grow or shrink on their own. This helps save resources and handle more users smoothly.

When you want to improve app speed by scaling only busy parts.

When different teams work on different app features separately.

When you want to update or fix one part without stopping the whole app.

When you expect some features to get more users than others.

When you want to use different tools or languages for different parts.

Syntax

NestJS

import { NestFactory } from '@nestjs/core';
import { MicroserviceOptions, Transport } from '@nestjs/microservices';
import { AppModule } from './app.module';

async function bootstrap() {
  const app = await NestFactory.createMicroservice<MicroserviceOptions>(AppModule, {
    transport: Transport.TCP,
    options: { port: 3001 },
  });
  await app.listen();
}
bootstrap();

This code creates a microservice using NestJS with TCP transport.

You can run many microservices on different ports to scale parts independently.

Examples

This example uses Redis transport for microservice communication.

NestJS

const app = await NestFactory.createMicroservice(AppModule, {
  transport: Transport.REDIS,
  options: { url: 'redis://localhost:6379' },
});

This example uses NATS transport, good for event-driven microservices.

NestJS

const app = await NestFactory.createMicroservice(AppModule, {
  transport: Transport.NATS,
  options: { servers: ['nats://localhost:4222'] },
});

Sample Program

This microservice listens on port 3001 and sums numbers sent to it. You can run many such microservices on different ports to scale only the parts you need.

NestJS

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

@Controller()
export class AppController {
  @MessagePattern({ cmd: 'sum' })
  sum(data: number[]): number {
    return data.reduce((a, b) => a + b, 0);
  }
}

import { Module } from '@nestjs/common';
import { AppController } from './app.controller';

@Module({
  controllers: [AppController],
})
export class AppModule {}

import { NestFactory } from '@nestjs/core';
import { MicroserviceOptions, Transport } from '@nestjs/microservices';
import { AppModule } from './app.module';

async function bootstrap() {
  const app = await NestFactory.createMicroservice<MicroserviceOptions>(AppModule, {
    transport: Transport.TCP,
    options: { port: 3001 },
  });
  await app.listen();
  console.log('Microservice is listening on port 3001');
}
bootstrap();

Important Notes

Each microservice runs alone, so you can add more instances of just the busy ones.

Microservices communicate over networks, so choose fast and reliable transport methods.

Scaling independently means less waste and better app performance.

Summary

Microservices let you grow parts of your app separately.

This helps save resources and handle more users smoothly.

NestJS makes it easy to create and run microservices on different ports or transports.

Practice

1. Why do microservices in NestJS allow independent scaling?

easy

A. Because NestJS combines all microservices into one big app

B. Because all microservices share the same database and scale together

C. Because each microservice runs separately and can be scaled on its own

D. Because microservices cannot be scaled independently

Solution

1. Step 1: Understand microservice independence

   Microservices run as separate processes or servers, each handling a specific task.

2. Step 2: Recognize scaling benefits

   Since they run separately, you can increase resources for one microservice without affecting others.

3. Final Answer:

   Because each microservice runs separately and can be scaled on its own -> Option C

4. Quick Check:

   Microservices run separately = scale independently [OK]

Hint: Microservices run alone, so scale them alone [OK]

Common Mistakes:

• Thinking all microservices share resources and scale together
• Believing NestJS merges microservices into one app
• Assuming microservices cannot scale independently

2. Which NestJS code snippet correctly creates a microservice that can scale independently?

easy

A. const app = await NestFactory.createMicroservice(AppModule, { transport: Transport.TCP, options: { port: 3001 } });

B. const app = await NestFactory.create(AppModule); app.listen(3001);

C. const app = await NestFactory.createMicroservice(AppModule, { transport: Transport.HTTP });

D. const app = await NestFactory.createMicroservice(AppModule, { transport: Transport.TCP, options: { port: 'not-a-number' } });

Solution

1. Step 1: Identify correct microservice creation syntax

   Using NestFactory.createMicroservice with Transport.TCP and a valid port number is correct.

2. Step 2: Check options validity

   const app = await NestFactory.createMicroservice(AppModule, { transport: Transport.TCP, options: { port: 3001 } }); uses port 3001 (a number), which is valid. const app = await NestFactory.createMicroservice(AppModule, { transport: Transport.TCP, options: { port: 'not-a-number' } }); uses a string for port, which is invalid.

3. Final Answer:

   const app = await NestFactory.createMicroservice(AppModule, { transport: Transport.TCP, options: { port: 3001 } }); -> Option A

4. Quick Check:

   Correct microservice syntax = const app = await NestFactory.createMicroservice(AppModule, { transport: Transport.TCP, options: { port: 3001 } }); [OK]

Hint: Use createMicroservice with valid transport and port [OK]

Common Mistakes:

• Using create() instead of createMicroservice() for microservices
• Setting port as a string instead of a number
• Using HTTP transport incorrectly for microservices

3. Given this NestJS microservice code, what will happen when you run it?

const app = await NestFactory.createMicroservice(AppModule, { transport: Transport.TCP, options: { port: 4000 } });
await app.listen();
console.log('Microservice running');

medium

A. The microservice fails because listen() needs a port argument

B. The microservice starts on port 4000 and logs 'Microservice running'

C. The microservice starts but on a random port, not 4000

D. The code throws a syntax error

Solution

1. Step 1: Understand createMicroservice with TCP transport

   Setting transport to TCP with port 4000 means the microservice listens on port 4000.

2. Step 2: Check listen() usage

   Calling listen() without arguments works because port is set in options during creation.

3. Final Answer:

   The microservice starts on port 4000 and logs 'Microservice running' -> Option B

4. Quick Check:

   Port set in options + listen() = runs on port 4000 [OK]

Hint: Port in options means listen() needs no argument [OK]

Common Mistakes:

• Thinking listen() always needs a port argument
• Assuming microservice picks random port if none given to listen()
• Confusing syntax errors with runtime behavior

4. What is wrong with this NestJS microservice setup code?

const app = await NestFactory.createMicroservice(AppModule, { transport: Transport.TCP, options: { port: 0 } });
await app.listen();

medium

A. Port 0 lets the OS assign a free port, so it works but port is unknown

B. The code is missing await before app.listen()

C. Port 0 is invalid and causes the microservice to fail

D. Transport.TCP is not supported in NestJS microservices

Solution

1. Step 1: Understand port 0 meaning in networking

   Port 0 tells the OS to assign any free port automatically.

2. Step 2: Check NestJS microservice behavior

   NestJS accepts port 0 and starts microservice on a random free port, so code works but port is not fixed.

3. Final Answer:

   Port 0 lets the OS assign a free port, so it works but port is unknown -> Option A

4. Quick Check:

   Port 0 means OS assigns port [OK]

Hint: Port 0 means OS picks free port automatically [OK]

Common Mistakes:

• Assuming port 0 is invalid and causes failure
• Forgetting await before listen() (though it is present here)
• Believing Transport.TCP is unsupported

5. You have three NestJS microservices: Auth, Payments, and Notifications. You want to scale only Payments during high load without affecting others. Which approach best uses microservices to achieve this?

hard

A. Use a single microservice for all features and scale it vertically

B. Combine all three services into one app and scale the whole app together

C. Run all microservices on the same port to share resources and scale together

D. Run each microservice on its own port and scale Payments service instances independently

Solution

1. Step 1: Understand microservice separation

   Running each microservice on its own port means they operate independently.

2. Step 2: Scale only Payments service

   You can add more instances of Payments microservice without touching Auth or Notifications.

3. Step 3: Avoid combining or sharing ports

   Combining services or sharing ports prevents independent scaling.

4. Final Answer:

   Run each microservice on its own port and scale Payments service instances independently -> Option D

5. Quick Check:

   Separate ports = independent scaling [OK]

Hint: Separate ports let you scale services alone [OK]

Common Mistakes:

• Merging all services into one app losing independent scaling
• Running all microservices on same port causing conflicts
• Using one service for all features limits scaling options