Why microservices scale independently in NestJS - Challenge Your Understanding

Challenge - 5 Problems

🧠 Conceptual

intermediate

Why can microservices scale independently?

In a NestJS microservices architecture, why is it possible to scale each microservice independently?

A Because each microservice runs in its own process and can be deployed separately.

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

C Because NestJS forces all microservices to use the same port, limiting scaling.

D Because microservices are combined into a single monolithic app that scales as one unit.

💡 Hint

Think about how microservices run and deploy in NestJS.

Each microservice runs as an independent process or container. This means you can add more instances of just one microservice without affecting others. This independence allows targeted scaling based on demand.

❓ component_behavior

intermediate

What happens when you scale a single NestJS microservice?

Given a NestJS app with three microservices, what is the effect of scaling only one microservice to multiple instances?

A Only the scaled microservice handles more requests; others remain unchanged.

B The scaled microservice stops communicating with others.

C The entire app crashes because microservices must scale together.

D All microservices automatically scale to the same number of instances.

💡 Hint

Consider how microservices communicate and deploy independently.

Scaling one microservice increases its capacity to handle requests. Other microservices continue running as before, unaffected by this change.

❓ lifecycle

advanced

How does independent scaling affect microservice lifecycle in NestJS?

When scaling a NestJS microservice independently, what lifecycle behavior is important to maintain smooth operation?

A Instances do not need to connect to the message broker when scaling.

B All instances share a single lifecycle and start together automatically.

C Each instance must initialize and register itself with the message broker separately.

D Scaling requires stopping all other microservices first.

💡 Hint

Think about how microservices communicate in NestJS.

Each microservice instance must connect to the message broker or transport layer independently to receive messages and requests. This ensures proper communication and load distribution.

📝 Syntax

advanced

Which NestJS microservice setup supports independent scaling?

Which code snippet correctly creates a NestJS microservice that can be scaled independently?

NestJS

import { NestFactory } from '@nestjs/core';
import { Transport, MicroserviceOptions } 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();

A The code creates a monolithic app that cannot be scaled independently.

B The code creates a microservice listening on port 3001, allowing independent deployment and scaling.

C The code uses HTTP transport which does not support microservices.

D The code is missing the call to app.listen(), so it won't start.

💡 Hint

Look at the transport and port configuration.

This code creates a TCP microservice on a specific port. Each microservice can run separately and be scaled independently by running multiple instances on different ports or hosts.

🔧 Debug

expert

Why does scaling a NestJS microservice cause message loss?

You scaled a NestJS microservice to multiple instances but notice some messages are lost. What is the most likely cause?

NestJS

import { NestFactory } from '@nestjs/core';
import { Transport, MicroserviceOptions } 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();

A The microservice instances are not connected to the database.

B The app.listen() method was not called, so the microservices never started.

C The microservices are using HTTP transport which does not support scaling.

D All instances are trying to listen on the same TCP port, causing conflicts and message loss.

💡 Hint

Consider how TCP ports work when running multiple instances.

TCP ports must be unique per instance. Running multiple microservice instances on the same port causes conflicts and lost messages. Each instance should use a different port or use a message broker transport that supports multiple consumers.

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