Why microservices scale independently in NestJS - Visual Breakdown

Concept Flow - Why microservices scale independently

Client Request

↓

API Gateway

↓

Route to Specific Microservice

↓

Microservice Instance

↓

Process Request

↓

Return Response

↓

Scale Decision

↓

Add/Remove Instances of Microservice

↓

Independent Scaling Achieved

The client request goes through an API gateway, which routes it to the right microservice. Each microservice runs separately and can be scaled up or down on its own, without affecting others.

Execution Sample

NestJS

import { Controller, Get } from '@nestjs/common';

@Controller('orders')
export class OrdersController {
  @Get()
  getOrders() {
    return ['order1', 'order2'];
  }
}

A simple NestJS microservice controller that handles requests for orders independently.

Execution Table

Step	Action	Microservice Instance	Scaling Decision	Response
1	Client sends request to API Gateway	N/A	N/A	N/A
2	API Gateway routes to OrdersService	OrdersService Instance 1	N/A	N/A
3	OrdersService processes getOrders()	OrdersService Instance 1	N/A	['order1', 'order2']
4	High load detected on OrdersService	OrdersService Instance 1	Scale up: Add Instance 2	N/A
5	New request routed to OrdersService Instance 2	OrdersService Instance 2	N/A	['order1', 'order2']
6	Load normalizes	OrdersService Instances 1 & 2	Scale down: Remove Instance 2	N/A
7	Request routed to OrdersService Instance 1	OrdersService Instance 1	N/A	['order1', 'order2']

💡 Scaling decisions allow adding or removing microservice instances independently based on load.

Variable Tracker

Variable	Start	After Step 4	After Step 6	Final
OrdersService Instances	1	2	1	1
Load on OrdersService	Normal	High	Normal	Normal

Key Moments - 2 Insights

Why does scaling one microservice not affect others?

Because each microservice runs as a separate instance, scaling decisions (like adding or removing instances) apply only to that microservice, as shown in steps 4 and 6 of the execution_table.

How does the API Gateway help in independent scaling?

The API Gateway routes requests to specific microservice instances, so when new instances are added or removed, it directs traffic accordingly without changing other services (see steps 2 and 5).

Visual Quiz - 3 Questions

Look at the execution_table, how many OrdersService instances exist after step 4?

A 2

B 0

C 1

D 3

💡 Hint

Check the 'Microservice Instance' and 'Scaling Decision' columns at step 4.

At which step does the system scale down the OrdersService instances?

A Step 5

B Step 6

C Step 3

D Step 7

💡 Hint

Look for 'Scale down' in the 'Scaling Decision' column.

If the API Gateway did not route requests properly, what would happen?

A Microservices would scale automatically

B All microservices would scale together

C Requests might not reach the correct microservice instance

D Load would decrease

💡 Hint

Refer to the role of API Gateway in steps 2 and 5.

Concept Snapshot

Microservices run as separate services.
API Gateway routes requests to each microservice.
Each microservice can add or remove instances alone.
Scaling decisions depend on load per microservice.
This allows independent scaling without affecting others.

Full Transcript

In microservices architecture, each service runs independently. When a client sends a request, it goes through an API Gateway that directs it to the correct microservice instance. Each microservice can process requests on its own. When load increases on one microservice, new instances of that service can be added without changing others. When load decreases, instances can be removed. This independent scaling is possible because microservices are separate and the API Gateway manages routing. This example shows an OrdersService handling requests and scaling up and down based on load.

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