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..

[trodix]

Just for clarification, if I have 300 instances of service A, for each one, a different JetStream consumer to one stream in NATS from service B, is it fine to have 300 consumers for one stream? what is the limit of instance for one stream? From a NATS perspective, is 300 consumers a big or a small amount?

[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.