How to organize queues?

Question

RabbitMQ

There is some application:
- several replicas of microservices (service_1) that hold a WebSocket connection with the client (either centrifuge)
- rabbitmq
broker - stateless business logic service (service_2) for communicating with the database
- redis for storing end-to-end data between service replicas The user

case is as follows:
1) the client connects to any instance of service_1, sends a command
2) the command is sent by service_1 to the broker
3) service_2 reads the command , knowing who and what is requesting
4) service_2 sends a command to the broker, which should be sent to the desired instance and then to the desired client

Question: how to properly organize the sending of the command service_2 -> service_1 ? The problem is how to find out which service which users are subscribed to ? store this relationship in redis ? Or for each user to create in turn ? Or is it all one queue and each message should be read by each instance of service_1 and then filtered ?

Answer 1

Of course, I missed the crocodile from another stack, but as an option:
the request goes to some kind of proxy, from where it transfers to the desired server by sha1 from the session identifier. because this logic will work only at the time of the handshake - it will not become a bottleneck. and if it hits the ceiling, then vertical scaling will cost a penny here (compared to the price of the rest of the infrastructure). If ping is important, you can also L4 (in front) and scatter it over different regions.
at this point, we already get a uniform distribution of users across servers AND the ability to understand, by id, on which server the connection is hanging. the most obvious problem is the automatic scaling of everything in both directions. more will have to juggle a lot. under conditions of not ideal connection/loaded mesh, there will be breaks here (but perhaps this is an acceptable compromise).

how to find out which service which users are subscribed to

by identifier, we immediately understand which particular instance to go to. if the connection is broken, go somewhere to the ocestrator to clarify where to send the data now.

store this relationship in redis

maybe in radish. as a matter of fact it is necessary to store only masks what range on what server go. and when scaling - update.

Or for each user to create in turn? Or is it all one queue and each message should be read by each instance of service_1 and then filtered?

to be honest, it looks like an overhead, I don’t see a problem to shove everything into 1 queue, from which the workers will rake up the work. just double-check that your queue really guarantees that the message will be read exactly 1 time, the same Amazon SKS has the wording about "exactly 1 time".

Answer 2

If the client does not close the connection to a specific instance (or if it closes, then it should not receive a response), then look towards RPC, that's how it works, here are examples .
If the result requires a lot of computing resources and it is undesirable to repeat, then either create queues for each client, or cache the result somewhere (for example, in a DBMS).

Answer 3

And what's the problem with sending both the user ID and the ID of the service (instance) to which it is connected from service_1 to the broker? Then each instance of service_2 will know to whom the command is intended. I see no reason to create queues for each user (and even more so to manage them) and even for each instance of service_1.
So I'm in favor of a simpler option:

Or is it all one queue and each message should be read by each instance of service_1 and then filtered?