Currently I have a .NET core application, which fires up a new thread to hold each customer account. Each thread instance:
- Is long running for many months or more
- Holds open SignalR Websockets and calls 3rd party APIs
- Needs to be super responsive
- Has 1 instance for every user account as it connects to unique web sockets / account APIs.
The current plan is to compile this to a Windows Service then deploy 1 application per server instance that uses all resources on the server, then have an orchestrator that manages controlling and deleting the threads through a RabbitMQ integration. We are imagining that 1 server instance could run up to 40 threads or something. Then the orchestrator would create new server instances to manage more accounts as we scale.
I am not happy with this approach as it feels clunky to me. Ideally I'd like to fire up each account instance in it's own Container using Kubernetes or similar, but the cost of running 1 user account per container is not financially viable.
Are there any other alternatives that anyone can recommend. Other things I've been thinking of are to create each account as a separate app as a Windows Service and then fire up multiple versions of the windows service on each server with some kind of service orchestrator.
I am fairly new to architecture like this, so go easy on me if I have not explained this properly. Any advice/ideas on how others could/would approach this would be most appreciated.