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.

  • 5
    The first thing that stands out to me is the idea that you need to run one account per instance of this thing. Why is that? Things like SignalR can connect to many, many clients and be responsive. I feel like there is either some constraint that I am missing here or the whole architecture of this thing needs to be examined more closely.
    – Becuzz
    Jul 16 '19 at 13:09
  • 2
    @HollandRisley it's still not really clear to me what problem having a dedicated thread per account is solving, nor why you'd need async/await to replace that. This problem is already solved by the web server/thread pool.
    – Ant P
    Jul 16 '19 at 13:14
  • 1
    @AntP, The more I think about this, the more I think you are right that I need to study the Thread Pool in more detail and keep all accounts running alongside each other in a single instance for the time being. Jul 16 '19 at 13:25
  • 5
    @HollandRisley any commercial database system will support many concurrent queries except in the event of an exclusive lock. Even if that weren't the case, adding more application threads has no bearing on the database. It sounds like you're trying to architect around problems that don't really exist. Of course, more application instances will generally improve your ability to handle a larger number of concurrent requests, but you definitely don't need a dedicated thread for each client.
    – Ant P
    Jul 16 '19 at 13:27
  • 5
    I'm not ready to say this definitely applies to your situation but many people new to concurrent programming get surprised when they learn that often throwing more threads at a problem actually slows you down because of the thread overhead. The ideal number of threads rarely has a 1 to 1 correspondence to anything in your business domain. The correct number is often something you have to tune after testing. This might be what you're meant to discover. Jul 16 '19 at 13:55

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.