TCP Transporter vs NATS for Service Discovery in Minimalist Deployments

Architectural Trade-off for Service Communication

When deploying a Moleculer-based microservice architecture, the choice of transporter determines how nodes discover each other and handle request routing. For environments where minimizing external infrastructure is a primary constraint, the built-in TCP transporter is often considered to avoid the operational overhead of a dedicated message broker.

Infrastructure Constraints and Discovery

The TCP transporter allows nodes to communicate directly, reducing the dependency chain. However, as the cluster scales across multiple hosts, managing direct connections and ensuring consistent service registry updates becomes more complex compared to using a centralized broker like NATS, which automates discovery and event broadcasting.

Request Failure Semantics

A critical uncertainty exists regarding how pending actions are handled when a transporter connection drops mid-request. Because TCP and NATS operate on different underlying protocols, the failure semantics—specifically regarding timeouts and retry policies—may not be uniform across these two options.

• Does the TCP transporter provide a consistent timeout mechanism for pending actions during a connection drop compared to the NATS transporter?
• Which transporter is more resilient for service discovery in a multi-host environment if an external broker is prohibited?