TCP Transporter vs NATS for Service Discovery in Minimalist Deployments

Answer

If an external broker is prohibited, the built-in TCP transporter is the only viable option. The NATS transporter requires a running NATS server; without it the cluster cannot form. For multi-host service discovery with no broker, TCP is more resilient in the sense that it has no external dependency, but it is less automatic than NATS.

Pending-action timeout behavior is not a TCP-vs-NATS difference. It is governed by Moleculer caller-side call options. A dropped transporter connection leaves a request pending until the caller timeout expires, then it fails or is retried according to the call options you set. Both transporters surface the failure through the same caller timeout and retry semantics.

Confirmed facts

• NATS centralizes registry and event fan-out. That improves convergence speed and reduces per-node peer churn, but it violates a no-external-broker constraint.
• TCP transporter avoids a broker dependency. Nodes communicate directly and maintain a peer registry. Discovery and registry updates are peer-to-peer.
• Multi-host TCP discovery is environment dependent. UDP-based discovery works only within a broadcast domain. Across subnets or NAT it is typically blocked, requiring static node lists or explicit configuration.

Likely explanation

Timeout and retry for pending actions are caller semantics, not transporter semantics. The transporter delivers or drops the message; the caller decides how long to wait and whether to retry. Therefore consistency between TCP and NATS for a connection drop is expected to be similar when Moleculer version, call options, and network conditions are held constant. Exact failure timing can still vary by version and transporter implementation, so treat defaults as version-sensitive.

Steps needed for this case

1. Confirm the no-broker constraint is hard. If a NATS server cannot be operated, eliminate NATS transporter.
2. Check discovery reachability. Can all hosts exchange UDP discovery/broadcast traffic, or must discovery cross subnets/NAT?
3. If UDP discovery is blocked, plan static node lists for TCP and accept manual registry maintenance on scale events.
4. Set explicit caller timeout and retry on critical actions and make actions idempotent. Do not rely on transporter-level defaults.

Verification

Reproduce with a two-node cluster. Call an action with an explicit short timeout and fixed retries, then stop the serving node or drop its transporter connection mid-call. Record timeout, retry, or hang. Repeat with TCP and NATS while holding Moleculer version, action options, and network conditions constant. Measure registry convergence after killing a node and note how quickly calls fail fast versus wait for timeout.

One missing diagnostic detail changes the recommendation: whether all hosts can exchange UDP discovery/broadcast traffic or whether discovery must cross subnets/NAT. If discovery must cross subnets/NAT, TCP will require static configuration and will be less resilient to churn than a brokered setup.