Why microservices scale independently in NestJS - See It in Action

Why microservices scale independently

📖 Scenario: You are building a simple NestJS microservices system for an online store. Each microservice handles a specific part: products and orders. You want to show how each microservice can scale independently by controlling the number of instances for each.

🎯 Goal: Create two NestJS microservices, ProductsService and OrdersService, with separate configurations for scaling. You will set up the basic services, add a configuration for the number of instances, and then apply that configuration to simulate independent scaling.

📋 What You'll Learn

Create a basic NestJS microservice for products

Create a basic NestJS microservice for orders

Add a configuration variable for the number of instances for each service

Use the configuration to simulate scaling by printing the instance count

💡 Why This Matters

🌍 Real World

Microservices allow different parts of an application to grow or shrink separately. For example, if product requests grow faster than orders, you can add more product service instances without touching orders.

💼 Career

Understanding how to configure and scale microservices independently is key for backend developers working with modern distributed systems and cloud deployments.

1

Create basic ProductsService microservice

Create a NestJS microservice class called ProductsService with a method getProducts() that returns an array with the strings 'Apple' and 'Banana'.

NestJS

// Create a NestJS microservice class called ProductsService
// Your code here

Hint

Use @Injectable() decorator and create a method that returns the exact array.

2

Create basic OrdersService microservice and add instance count config

Create a NestJS microservice class called OrdersService with a method getOrders() that returns an array with the strings 'Order1' and 'Order2'. Then create two constants: PRODUCTS_INSTANCES set to 3 and ORDERS_INSTANCES set to 5 to represent the number of instances for each service.

NestJS

import { Injectable } from '@nestjs/common';

@Injectable()
export class ProductsService {
  getProducts(): string[] {
    return ['Apple', 'Banana'];
  }
}

// Create OrdersService class and instance count constants
// Your code here

Hint

Use @Injectable() for OrdersService and create two constants with the exact names and values.

3

Simulate scaling by using instance count in a method

In ProductsService, add a method getInstanceCount() that returns the value of PRODUCTS_INSTANCES. In OrdersService, add a method getInstanceCount() that returns the value of ORDERS_INSTANCES.

NestJS

import { Injectable } from '@nestjs/common';

@Injectable()
export class ProductsService {
  getProducts(): string[] {
    return ['Apple', 'Banana'];
  }
  // Add getInstanceCount method here
}

@Injectable()
export class OrdersService {
  getOrders(): string[] {
    return ['Order1', 'Order2'];
  }
  // Add getInstanceCount method here
}

export const PRODUCTS_INSTANCES = 3;
export const ORDERS_INSTANCES = 5;

Hint

Define getInstanceCount() methods that return the constants for each service.

4

Complete by exporting all services and constants

Export ProductsService, OrdersService, PRODUCTS_INSTANCES, and ORDERS_INSTANCES from the module so they can be used elsewhere.

NestJS

import { Injectable } from '@nestjs/common';

@Injectable()
export class ProductsService {
  getProducts(): string[] {
    return ['Apple', 'Banana'];
  }

  getInstanceCount(): number {
    return PRODUCTS_INSTANCES;
  }
}

@Injectable()
export class OrdersService {
  getOrders(): string[] {
    return ['Order1', 'Order2'];
  }

  getInstanceCount(): number {
    return ORDERS_INSTANCES;
  }
}

export const PRODUCTS_INSTANCES = 3;
export const ORDERS_INSTANCES = 5;

// Export all services and constants here
// Your code here

Hint

Use a single export statement listing all four identifiers.

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