What to use to implement EDA in microservice architecture?

Question

RabbitMQ

We are building a kubernetes cluster with colleagues. The idea is that the front communicates with the back through nautilus, and the back communicates with each other through a message broker, or something like that. Now they installed rabbitMQ, and realized that they apparently missed the choice.

As we see it:
One microservice performs some action that came from nautilus. This microservice notifies all other microservices about the changes made by placing a notification in the broker. Type "User 113 - deleted". Therefore, other microservices, seeing this notification, read it and perform the necessary actions on their own (for example, delete related objects).

What is the problem with Rabbit:
As soon as the first consumer (microservice) reads the message in the queue, it is deleted.

What's the question:
Have we configured something wrong? We need the message not to be deleted. If the rabbit does not fit, what is better to use? We look towards Radis or Kafka.
There is no question about the highload.

Answer 1

RabbitMQ is about queues, if you have a queue of tasks, then I don’t think you want all workers to perform the same action. If you want each service to receive a copy of the message, they must have independent queues that can be subscribed to the same exchange.
If you can have N instances of one service, then all N subscribe to the same queue (otherwise, see what happens above), but each service must have its own queue.
Read the basic RabbitMQ manuals - https://www.rabbitmq.com/getstarted.html - you will find a lot of useful things there (there are translations into Russian on Habré, if necessary)
For example, for simplicity, let's assume that there is only one exchange - events. There are two services - S1 and S2. Each of them has 3 instances. Services want to receive all messages that are published in events.
We get (assuming there is nothing yet):
- create an events exchange (preferably before everything starts) with the fanout type
- the first S1 instance creates a queue at startup - events-s1; creates a binding of this queue for exchange events; subscribes to this queue
- the second and third instances of S1 see at startup that there is a queue and simply subscribe to it
- the same thing is repeated for S2
With the growth of services, one exchange may not be enough, then one queue may have more than one binding to the exchanges it needs. Or you can change the type of the extension to topic and control who will receive messages through the binding keys and message headers, and not the names of the extensions.