Rabbit MQ in the residents call handling system

Recently, users successfully commissioned a system for processing citizens' appeals. The essence is that when you do not have water at home, heating, or there is a huge pit on the road near your house, you can complain about the problem to state agencies. There are different platforms where you can submit an application with a complaint: the websites of state institutions, pages in social networks, call centers.

Our task was to create a single pipeline for processing applications for all departments.
The main goal of the system is to speed up the processing of requests as much as possible: to automate everything automated, to control the time at each stage of the process, to inform residents about each step.

One of the specific tasks of the project was the issue of integration with a large number of external systems.

• It was necessary to learn from different sites to take the entire stream of complaints, to be able to communicate with them on all changes with applications, to conduct correspondence between government officials and citizens to clarify the details of complaints.
• In addition, this is part of the functions we have given to third-party services.

Since There were a lot of data, often we had to work in asynchronous mode, then the project team had to decide the question, no matter how hard it was for third-party systems. The solution was found in the Rabbit MQ software message broker. It was a new technology for the team at that time.

Below is an interview with WilyLynx, the project backend developer Alexander Shcheglov, who dealt with the question and implemented the integration.

- Sash, hello! Please tell us briefly what is Rabbit MQ?

The software is intended mainly for the implementation of deferred messaging between different clients, i.e. when you don't need an answer right now.

- I understand correctly that in general it works like this: does the sending service put data in the created queue as it is generated, the receiving service takes this information as needed?

That is how it works.

- Why did you (the development team) choose this solution for the project?

For several reasons. Firstly, in our case, synchronous processing (received and processed at the same time) is not a critical message, i.e. the message may be in the queue for some time. In addition, ease of use: to receive messages, you only need to declare the name of the queue and there is no need to write your services. Well, the presence of libraries for common PL. No need to invent something to work with RabbitMQ.

- Correctly understand that Rabbit MQ allows you to manage data exchange between systems and web services?

Rather, we still manage the exchange, but the “rabbit” is an excellent tool for organizing this exchange. Here you have the lifetime of messages in the queues, and the maximum queue length, and access setup, and clustering, and various exchange protocols, and the plugin system, and so on.

- How is the message delivered? - that is, how is it determined that the client continued something after receiving it or was hanging in the process?

It is considered to be delivered if within a certain period of time a response comes from the client. In it, in fact, it says that he received and was pleased with life. The client can send a response as soon as received, and then try to process the message. It may, on the contrary, first try to process and, upon successful processing, send a response. And you can tell the rabbit in advance so that he does not expect you to confirm delivery and just receive messages. All sent items will automatically be considered delivered.

- Is it possible, for example, to receive messages not all in some way, but for example, only subscribe to messages on a specific application?

There is a slightly different situation. There is the option of sending messages, in which messages come to all customers. This option is called "publish / subscribe". A good example: a new message in your public. You sent, all signatories received. And already upon receipt, they thought, to read or not to read. In general, no one bothers you to create a separate queue for yourself and work only with it. In this case, routing will already be at the application level, and the rabbit will be the communication channel.

- Sasha, say, there is an option not to create thousands of queues, but to do filtering, routing for one?

One will not work, but Rabbit will allow some routing.

- Tell me more, please.

From one not, but there are such concepts of “exchange" and "routing key":

P - producer, the sender of the message in exchange (exchange)
X - the exchange itself
Red stripes - queues
C1 and C2 - recipients



Pabbit can send a message in exchange with a specific key (for example, error / info / warning). And as you can see, different recipients are sharpened to receive messages with different routing key. Moreover, the message with the key “info” will receive only C2, and with the key “error” both will receive. It is also possible to receive messages on a key template. This is for another type of exchange "Publish / Subscribe", about which I have already spoken.



As you can see, in any case, each of the recipients in these types of exchange has its own line, but in the end we still have some semblance of filtering / routing.

- What can you remember the problems that arose in the process of studying and implementing Rabbit?

Except no laziness. Seriously, understandable documentation, a large number of examples.

- Have you already transferred all exchanges with services and external systems to it?

We now have 38 queues: the exchange between circuits, external systems, BI. But unfortunately, some services (read the departments) resist. because they implemented rest. In addition, some types of interactions involve the simultaneous receipt of responses to requests.

- How do you think how successful this decision was?

For interdepartmental interaction, not requiring a synchronous response? For me, so a great option.

List of materials used