Multiple servers for each module or one server to handle requests from multiple clients

Question

We got multiple devices that communicate over different protocols (rs232, tcp, http, etc.) and we want be able to send requests from multiple interfaces (as well get responses from each device to multiple interfaces).

We are wondering how to properly manage the communication between interface clients and device clients. One solution is to make a server manager which will handle one connection to multiple interface clients and one connection to multiple modules. But, I'm not a fan of it due to multithreaded code that should be manage. Diagram:

So mine proposal is to make a manager which have got multiple servers, so each module and specified interface will be clients that communicate with concrete module server. Diagram:

Which one is better and why? In mine opinion the version with multiple servers will separate multithreaded logic for each module. On the other hand we will have multiple connections, but is it a thing to worry about it?

Thanks in advance.

Answer 1

I don't know how big a project this is, but it seems to me this shouldn't be a matter of taste. There are design factors to consider. Your team should brainstorm on design factors and then rate them for risk, cost, and probability, then use some sort of objective scoring methodology to rank your options, both of which are perfectly viable for different situations.

Some questions for your group to consider:

How much risk is there that different inbound protocols will conflict with one another? You might want more process isolation if, say, your RS232 driver is leaky. Or maybe it is known to crash the box occasionally, in which case you'd want it to run on a separate machine entirely. Or maybe they're all completely stable, but you want their threads treated differently, e.g. different sized pools, shorter timeouts, or independent config.

Is there state? What is the impact of resetting any of the services? Do you have redundancy?

How fast are you going to grow? If you plan to grow fast, maybe you should try as hard as you can to get all the services running on a single box, so you can scale out more easily.

How complicated is the business logic? If your services are just sort of pass-through to the back end services, option 2 doesn't look so bad. If they are very complicated then option 1 is better.

What will be the release cycle? When you need to deploy bug fixes, is there any advantage to having separate services? Do you plan to synchronize feature releases, or will some channels get releases more often? Will the code be managed by different teams?

Also, be sure to engage your network engineering team, as it sounds like this solution is going to require a lot of plumbing and there may be connectivity concerns as well.

Answer 2

Always multiple servers, as a server may get busy in serial communication unless it times out and during that period will not process other communications.

Use multiple communicating entities and create a telegram processing queue with buffers.

Answer 3

Solution one in batter, but you could split it in 2 or 3 micro-servers, that comunicate using some messaging protocol (there are a few, like zeromq).

A combination between 1 and 2 is also nice, have a server that hanles all clients and redistribute communication to each device.

And in general use real server apps, don't implement your own in comunication with desktop clients.

Issues with sol 2:

• complexity on the client
• dificult to change client interface
• bad separation of concerns

Answer 4

First, the benefit of the first architecture is that clients a single interface they are connecting to and using. The second architecture benefit is that it scales well and different connections are used to different resources - but now you lost the first architecture advantage.

I suggest a mixture of both: Have a single API in the server, and by use of a parameter decide how to handle different requests. This was not needed in the second architecture since different clients had different contact point within the server, so this adds a bit of complexity and changes.

Allow me to reiterate a major point: The server itself might be splited into more than one service, but it has a single API