Is having a bi directional message queue a design smell?

Question

I have an architecture with 1 backend server and multiple frontend servers.

The frontend servers are connected in a bi-directional (web sockets) connection to clients so they can send messages to clients.

The frontend and backend are connected through a message bus. There is one queue for frontend to backend messages and another queue for backend to frontend messages.

For example, when a client requests an operation, the frontend sends the request to the backend and acknowledges the client the request was sent.

Sometimes, when the backend finishes handling a request, it sends a status message to the frontend who forwards it to the client that requested the operation.

I've never seen anything similar. Usually the communications only go one way - from frontend to backend.

I'm worried, am I doing something bizarre?

I came up with this architecture because of the bi-directional nature of web sockets. This way the server can notify clients as soon as a request is processed.

Answer 1

Communications do not usually only go one way. Parties usually communicate using request-response pairs, which are clearly not one way. I presume that you already know this, so what you are probably thinking when you say "one-way" is not how information flows, but who initiates the requests.

So, yes, the way we usually do things is that only one of the parties initiates requests. Which means that the other party always sends responses.

But there is an exception: the "callback", otherwise known as the "notifier-observer" pattern. It is perfectly fine for one side to send a "register observer" request to which the other side will immediately respond with an "observer registered" response and then, in the future, with one or more "event observation" responses.

Your terminology with "front-end servers" and "back-end servers" and other unrelated entities you call "clients" only confuses things, and you should not have brought it into the discussion. Things are very simple: Within the context of a communication session between two parties, the requesting party is always called a client, and the responding party is always called a server. In your case, your server is what you call a "back-end server", and your client is what you call a "front-end server".

EDIT:

Of course, in order to accomplish two-way communication you need to employ two queues. I have worked on one large-scale system which employed two queues per pair of modules that communicated, (one queue for each "way" in the "two-way",) so trust me, it is not something bizarre.