NestJS — Enterprise Node.js

Microservice Transports: Redis, MQTT & NATS

18 min Lesson 68 of 80

Microservice Transports: Redis, MQTT & NATS

The earlier microservices lessons covered TCP, RabbitMQ, Kafka, and gRPC. NestJS also supports Redis, MQTT, and NATS transporters, each aimed at different messaging needs and operational tradeoffs.

Core idea

This feature is about controlling how the application is organized and how it behaves at runtime. These are the points a developer should understand before using it in a real project:

Redis transport is simple for lightweight pub/sub-style communication but is not the same as durable Redis Streams.
MQTT is common for IoT and device messaging where topics and constrained clients matter.
NATS is lightweight, fast, and well suited for service messaging with subject-based routing.
Transport choice affects delivery guarantees, back pressure, ordering, observability, and operations.
ClientProxy abstracts the client API, but each driver still has different connection and deployment behavior.

Practical example

The following example shows the idea in a practical NestJS project. The goal is not to memorize the snippet, but to understand where it belongs in the architecture:

ClientsModule.register([
  {
    name: 'INVENTORY_CLIENT',
    transport: Transport.NATS,
    options: { servers: ['nats://localhost:4222'] },
  },
]);

@Controller()
export class InventoryEventsController {
  @EventPattern('inventory.reserved')
  handleReserved(@Payload() event: InventoryReservedEvent) {
    return this.projection.update(event);
  }
}

Design note: Do not choose a transporter only because it is easy to configure locally. Choose based on production semantics: durability, retry model, ordering, consumer groups, and operational ownership.

Production checklist

Document delivery expectations for every message pattern.
Set connection status monitoring for clients and servers.
Design idempotent consumers for at-least-once transports.
Avoid using pub/sub transports for workflows that require durable replay unless the broker supports it.

Rule of thumb: If the feature makes boundaries clearer and tests easier, it is probably the right choice. If it hides dependencies or makes tracing harder, redesign.

Summary

This lesson covers an advanced NestJS area that matters when building enterprise applications. Focus on clear boundaries, testable behavior, and choosing the right tool for the context instead of using every feature everywhere.