I am trying to search for a framework or library or even techniques for handling N-Tier Client/Server communications.

I am scaling my application software and I am seeing this communication becoming more and more cumbersome. I have an application server, but I also have middle servers for scaling the capacity of connected clients UI data processing and exchanging.

In my architecture I have a Server, which can have N Client Engines, which can have N clients.

Specifically, I am running into issues around the following scenario. I will use authentication as an example ( although it is a simple one but it gets the point across ).

A client ( Angular web client ) logs in via a websocket endpoint of a Jetty webserver. The message is forwarded to the queue of the Client engine. The client engine, when it processes the message, creates a request for the server and queues it up. The server, when it processes that message, performs the authentication. Now that response has to work its way back up the stack. The server has to queue a response message to the (right) Client Engine, then when the Client Engine processes that message, it has to send a message to the (right) client connection via the websocket endpoint.

Now this is all certainly possible and I have done it by just mapping the right information into the message and persisting that information inside each message until it gets back to the client.

However, this feels kinda clunky for me. I figured I am not the first person to have this problem. However, I don't think I understand what this problem is called because my search terms like: Async Programming, Client Server communication model, Client Server Server communication model, N-Tier communication model etc have not delivered on what I am looking for.

Is there a specific name for this problem?

I wanted to provide more details on the N-Tier system I have.

  • Tier 1 - Database Server ( data persistence ) 1 instance
  • Tier 2 - ApplicationServer ( in-memory solution ) 1 instance
  • Tier 3 - Delta Server ( delta forwarding to N Client Engines ) N instances
  • Tier 4 - Client Engine ( synchronizes data, session management, read-only transactions ) M instances
  • Tier 5 - Web Server ( Websocket Server ) M instances
  • Tier 6 - Client ( Angular Webapp )
  • Is there a specific name for this problem? Yes: Too Much Abstraction. Unless, of course, you actually need it. Nov 23, 2017 at 5:46
  • Haha. Agreed. I do actually need it though to support specific cases where the solution needs to scale. Most use cases for the software will not need tier 3 and will only have 1-2 Client Engines depending on the number of concurrent users. However, without the scalability the software will run into trouble, hence the N-Tier design.
    – Mark
    Nov 23, 2017 at 5:57

1 Answer 1


It sounds like your central complaint is routing:

The server has to queue a response message to the (right) Client Engine, then when the Client Engine processes that message, it has to send a message to the (right) client connection

I have had good experiences with kafka channels, where a worker bee subscribes to a channel naming its responsibility, and sends its computed result to the next-stage channel. It scales flexibly as workers come and go. Clearly if you have C client frontends, you will need C distinct channels and will need to retain that channel name in the request as it hops from queue to queue.

Let your message queue infrastructure deal with your routing problems, rather than make your apps do much worrying about it.

  • Perfect!! Routing... seems so obvious now. I will certainly look into Kafka!
    – Mark
    Nov 23, 2017 at 16:51

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.