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:

  1. Why why everybody says we need a message queue server?
  2. What can be the downside of removing message queue server and implementing queue inside the WebSocket server?


Trả lời

Email của bạn sẽ không được hiển thị công khai. Các trường bắt buộc được đánh dấu *