Using NATS through internet, is it bad to have a permanent opened connection?

[trodix]

Hi,

I'm working for a company where our main product (service A) is installed on premise (each instance could have ~500 swing clients connected to it and those swing clients are also communicating with a second product, alse on premise, on the same network (service B).

Now we want to make Service B a cloud service :

Is it okay to have a permanent opened socket between service A (local network) and NATS from service B (cloud)?
What about the connection stability? is it reliable? Does NATS connectReconnect capability is suited for this use case?

[derekcollison]

We at Synadia run a global service, Synadia Cloud, that is open to the public internet and is in every major geo and on al three of the big cloud providers.

We think this can be safe and secure. If you are worried about DOS or DDOS you could enable ipfw rules for bad actors but still have the client ports open.

On a cloud provider, we usually do server inter-connects (routes, gateways) over private networks though..

[derekcollison]

Is the stream a WorkQueue or InterestPolicy based stream?

[trodix]

It's a WorkQueue, where each instance of service A represents one of our customer that consume it's own events from it's filtered subjects on the stream. (ex: my-subject.customer-a.success, my-subject.customer-a.error, my-subject.customer-b.success, my-subject.customer-b.error etc...)

Maybe I need one stream per customer to avoid messages for customer A to be sent to every customers.
It would instead be 300 WorkQueue based streams and one consumer for each stream

[derekcollison]

WQ (and InterestPolicy) force consumers to have the same replica count as the parent stream. NATS systems should watch how many NRG (NATS Raft Groups) are in the system. Every replicated JetStream asset, streams and consumers, count as an NRG group.

You can restrict a consumer to only being able to pull items for itself.

If 300 is the top number, you should be ok, but if 300 scales with your customer set, you may want a different approach.

[trodix]

Just to be sure what i'm doing, if I use a push-based subscriber, 300 connections will be kept open on the server hosting my NATS instance. Do you confirm this amount of permanently opened connections on a same server should not cause issues?

If this could be a problem, what are my options? Maybe 300 pull-based subscribers may overload the NATS instance, this is the reason I did not choose this approach but maybe I'm wrong here.

[derekcollison]

Correct, NATS is designed to have long lived connections that are async in nature, meaning clients do not need connection pooling which is required up synchronous protocols.

The server can easily handle very large number of connections. The layout of the system should take into account how many connections would need to reconnect if a server is restarted or goes away for some reason, especially if TLS with large RSA keys is being utilized.