Microservice transports in NestJS - Cheat Sheet & Quick Revision

Recall & Review

beginner

What is a microservice transport in the context of NestJS?

A microservice transport is the communication method used by microservices to send and receive messages. In NestJS, transports define how microservices connect and exchange data, such as TCP, Redis, or MQTT.

beginner

Name three common transport layers supported by NestJS microservices.

TCP, Redis, and MQTT are three common transport layers supported by NestJS for microservice communication.

intermediate

Why is TCP transport often used for microservices in NestJS?

TCP transport is used because it provides a reliable, fast, and simple connection-oriented communication channel between microservices, suitable for many internal service calls.

intermediate

How does Redis transport help in microservice communication?

Redis transport uses Redis Pub/Sub to enable asynchronous message passing between microservices, which helps decouple services and supports event-driven architectures.

advanced

What is the main advantage of using MQTT transport in NestJS microservices?

MQTT transport is lightweight and designed for unreliable networks, making it ideal for IoT or mobile microservices that need efficient, low-bandwidth communication.

Which NestJS transport uses a publish-subscribe model for messaging?

A Redis

B TCP

C gRPC

D HTTP

Redis transport uses the publish-subscribe model to send messages asynchronously between microservices.

What type of communication does TCP transport provide in NestJS microservices?

A Multicast only

B Connectionless and unreliable

C Broadcast only

D Connection-oriented and reliable

TCP transport provides a connection-oriented and reliable communication channel.

Which transport is best suited for IoT devices in NestJS microservices?

A Redis

B TCP

C MQTT

D HTTP

MQTT is lightweight and designed for unreliable networks, ideal for IoT devices.

In NestJS, which transport layer supports asynchronous event-driven communication?

A Redis

B TCP

C WebSocket

D HTTP

Redis transport supports asynchronous event-driven communication using Pub/Sub.

Which of the following is NOT a built-in NestJS microservice transport?

A TCP

B HTTP

C Redis

D MQTT

HTTP is not a built-in transport in NestJS; it requires custom implementation or third-party packages.

Explain the differences between TCP, Redis, and MQTT transports in NestJS microservices.

Think about how each transport handles message delivery and network conditions.

Describe a real-life scenario where you would choose Redis transport over TCP in a NestJS microservice architecture.

Consider when services should not wait for immediate responses.

Practice

1. Which transport method in NestJS microservices is best suited for simple, direct communication between services on the same network without message brokering?

easy

A. TCP transport

B. Redis transport

C. RabbitMQ transport

D. Kafka transport

Solution

1. Step 1: Understand transport types in NestJS

   TCP transport is a simple protocol for direct communication between services on the same network without needing a message broker.

2. Step 2: Compare with other transports

   Redis, RabbitMQ, and Kafka are message brokers used for more complex messaging patterns and scalability.

3. Final Answer:

   TCP transport -> Option A

4. Quick Check:

   Direct network communication = TCP transport [OK]

Hint: Direct service communication without brokers uses TCP transport [OK]

Common Mistakes:

• Confusing Redis or RabbitMQ as direct transports
• Thinking Kafka is a simple direct transport
• Assuming TCP requires a message broker

2. Which of the following is the correct way to set up a RabbitMQ transport in a NestJS microservice?

easy

A. Transport.KAFKA with topic and brokers

B. Transport.TCP with host and port only

C. Transport.REDIS with channel and password

D. Transport.RMQ with options including urls and queue

Solution

1. Step 1: Identify RabbitMQ transport setup

   RabbitMQ transport in NestJS uses Transport.RMQ and requires options like urls (connection strings) and queue name.

2. Step 2: Differentiate from other transports

   TCP uses host and port, Redis uses channel and password, Kafka uses topic and brokers, so these are incorrect for RabbitMQ.

3. Final Answer:

   Transport.RMQ with options including urls and queue -> Option D

4. Quick Check:

   RabbitMQ setup = Transport.RMQ + urls + queue [OK]

Hint: RabbitMQ transport always uses Transport.RMQ with urls and queue [OK]

Common Mistakes:

• Using TCP options for RabbitMQ
• Confusing Redis channel with RabbitMQ queue
• Omitting urls in RabbitMQ config

3. Given the following NestJS microservice code snippet, what will be the output when a message is sent to the Redis transport?

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

app.listen(() => console.log('Microservice is listening'));

medium

A. Microservice failed to start due to invalid transport

B. Error: Missing queue or channel option

C. Microservice is listening

D. Microservice connected to RabbitMQ

Solution

1. Step 1: Analyze the transport configuration

   The code uses Transport.REDIS with a valid Redis URL, which is sufficient for Redis transport in NestJS.

2. Step 2: Understand the listen callback

   The listen method's callback logs 'Microservice is listening' when the microservice starts successfully.

3. Final Answer:

   Microservice is listening -> Option C

4. Quick Check:

   Valid Redis config logs listening message [OK]

Hint: Valid Redis transport logs 'Microservice is listening' on start [OK]

Common Mistakes:

• Expecting queue option for Redis transport
• Confusing Redis with RabbitMQ setup
• Assuming error without testing listen callback

4. Identify the error in this NestJS microservice transport configuration:

const app = await NestFactory.createMicroservice(AppModule, {
  transport: Transport.RMQ,
  options: {
    urls: ['amqp://localhost:5672'],
    queue: ''
  }
});

medium

A. The urls array should be a string, not an array

B. The queue name is empty, which is invalid

C. Transport should be TCP, not RMQ

D. Missing Redis password in options

Solution

1. Step 1: Check RMQ options correctness

   RabbitMQ transport requires a non-empty queue name to route messages properly.

2. Step 2: Validate other options

   The urls option is correctly an array of connection strings; transport RMQ is correct; Redis password is irrelevant here.

3. Final Answer:

   The queue name is empty, which is invalid -> Option B

4. Quick Check:

   Empty queue name causes config error [OK]

Hint: RabbitMQ queue name must not be empty [OK]

Common Mistakes:

• Thinking urls must be a string
• Confusing transport type with Redis
• Ignoring empty queue name error

5. You need to design a NestJS microservice system that can handle high message throughput with guaranteed message delivery and supports multiple consumers. Which transport should you choose and why?

hard

A. RabbitMQ transport, because it supports message queues with acknowledgments and multiple consumers

B. Redis transport, because it supports pub/sub and persistence

C. TCP transport, because it is simple and fast for high throughput

D. In-memory transport, because it is the fastest for local communication

Solution

1. Step 1: Identify requirements for high throughput and guaranteed delivery

   Guaranteed delivery and multiple consumers require a message broker with queueing and acknowledgment features.

2. Step 2: Evaluate transport options

   TCP is simple but lacks message queueing; Redis supports pub/sub but has limited message durability; RabbitMQ supports queues, acknowledgments, and multiple consumers; in-memory is local only and not scalable.

3. Final Answer:

   RabbitMQ transport, because it supports message queues with acknowledgments and multiple consumers -> Option A

4. Quick Check:

   Guaranteed delivery + multiple consumers = RabbitMQ [OK]

Hint: Use RabbitMQ for guaranteed delivery and multiple consumers [OK]

Common Mistakes:

• Choosing TCP for guaranteed delivery
• Assuming Redis persistence equals RabbitMQ reliability
• Using in-memory transport for distributed systems