I’m engineering architecture of a new web based software.
I’ve never worked on high-scale softwares before and I’m reading a lot about it.
To increase client-side speed and reduce load on servers, and also enabling server-to-client communication, I decided to use WebSockets.
To process request from clients, I always read, hear and watch here and there that I need to push requests from WebSocket to a message queue and then pop those messages to a worker, then process data and push results to message queue again, then pop to the WebSocket server then finally send the result back to the client.
Here is a simple schematic that what they say:
Client -> WebSocket -> Message Queue -> Worker Process -> Message Queue -> WebSocket -> Client
But when I think of this architecture, Message Queue seems an unneeded. Actually I believe that in this architecture, WebSocket can be a message queue itself. It gets messages from client, then sends them to another place.
All we need to do is register worker processes in WebSocket server as a Worker, then when a messages receives from client, directly send the message to an idle worker, and if there is no idle worker available, keep the message in a FIFO queue and when a worker becomes available, send oldest message to that worker.
This way, we get rid of message queue server.
Here is a simple schematic that what I mean:
Client -> WebSocket -> Worker Process -> WebSocket -> Client
So here is my questions:
- Why why everybody says we need a message queue server?
- What can be the downside of removing message queue server and implementing queue inside the WebSocket server?
5