Choosing a Moleculer Transporter: Decision Guide for NATS, Redis, and AMQP

Decision: Selecting a Moleculer Transporter

In Moleculer, the transporter is the communication layer that enables service discovery and message routing. Choosing the wrong transporter can lead to silent event loss during service restarts, unexpected latency spikes in request-response cycles, or unsustainable operational overhead.

Constraints and Requirements

Before selecting a transporter, evaluate your architecture against these four constraints:

• Delivery Durability: Do events need to be persisted if the consumer or the broker is offline?
• Latency Sensitivity: Do you require sub-millisecond RPC responses, or is a 10-50ms overhead acceptable?
• Operational Overhead: Does your team have the capacity to manage a new broker (like RabbitMQ) or should you leverage existing infrastructure (like Redis)?
• Topology: Are you running a single-process application for testing, or a distributed mesh across multiple containers?

Transporter Comparison Matrix

Transporter	Persistence	Typical Latency	Ops Burden	Best Fit
NATS	None (In-memory)	Very Low	Low	High-frequency RPC, stateless services
NATS JetStream	Disk-based	Low-Moderate	Moderate	Event-driven architectures needing replay
Redis	None (Pub/Sub)	Low-Moderate	Low (if existing)	Small-to-medium stacks already using Redis
TCP	None	Lowest	Zero (No broker)	Tightly coupled, low-node count setups
AMQP	Persistent Queues	Moderate	High	Enterprise routing, strict delivery guarantees

Trade-off Analysis

NATS is the recommended default for most Moleculer projects because it aligns with the framework's request-reply pattern and is lightweight. However, standard NATS is "fire-and-forget"; if a service is down when an event is emitted, that message is lost. To solve this, NATS JetStream adds a persistence layer, though it requires more careful storage planning.

Redis is a convenient choice if it is already present in your stack for caching. However, Redis Pub/Sub does not provide message queuing or durability. If a consumer disconnects, it misses all messages sent during that window. AMQP (RabbitMQ) provides the strongest delivery guarantees and complex routing, but it introduces significant operational complexity compared to NATS.

The TCP transporter eliminates the need for an external broker, reducing infrastructure costs. The trade-off is the loss of mature ecosystem tooling and a more fragile discovery mechanism compared to broker-based systems.

Implementation and Validation

To implement a transporter, you must install the specific adapter package and configure the broker. The following example demonstrates a setup using NATS.

1. Install the adapter:

   # Run in your project root
   npm install moleculer-transporter-nats

2. Configure the Broker:

   In your moleculer.config.js or broker initialization file:

   const { ServiceBroker } = require("moleculer");
   
   const broker = new ServiceBroker({
     transporter: "NATS",
     transporterOptions: {
       address: "nats://localhost:4222", // Replace with your NATS server address
     },
   });

3. Define a Service with an Event:

   // services/order.service.js
   module.exports = {
     name: "order",
     actions: {
       create(ctx) {
         const order = { id: 123, status: "created" };
         // Emit event to the transporter
         this.broker.emit("order.created", order);
         return order;
       }
     }
   };

Verification and Testing

To verify the choice of transporter, perform the following checks:

• Broker Failure Test: Kill the broker process while services are running. Observe if the services reconnect automatically once the broker is restarted.
• Durability Check: If using NATS JetStream or AMQP, stop a consumer service, emit an event, and then restart the consumer. Verify that the consumer processes the missed event. (Standard NATS/Redis will fail this test).
• Latency Baseline: Use broker.call in a loop of 1,000 requests and measure the average response time to ensure it meets your application's SLA.

Rollback Procedure

Since changing a transporter modifies the communication layer, you must update all services simultaneously. To rollback:

1. Revert the transporter string in moleculer.config.js to the previous value.
2. Ensure the previous broker infrastructure is active.
3. Restart all service instances to clear the internal service registry and reconnect to the old broker.