2

I was talking with part of my team about the responsibility for who own the Binding and Queue creation. We are using Spring framework.

In async communication they agree that the responsability to create the Binding and Queue is of the Consumer. Until here, we all agree.

But they understand that this is not true for sync (RPC - Remote Procedure Call) communication.

They prefer this model:

Producer1: Exchange, RoutingKey, Binding (RoutingKey, Queue)
Producer2: Exchange, RoutingKey, ​Binding (RoutingKey, Queue)
Consumer: Queue

Their reasons:

  1. The Producer sends a command (not an event, like in the async communication). Because the Producer is the main interested in the response, the setup stays on him.
  2. The Consumer only needs to know about the Queue. Does not matter who sends the message to him.

However, I not see in that way.

The model that I support is:

Producer1: Exchange, RoutingKey
Producer2: Exchange, RoutingKey
Consumer: Exchange, Binding (RoutingKey, Queue)

My reasons:

  1. The knowledge of Binding is from who consumes the Queue, like in the async communication
  2. One single point to declare and change the Binding and Queue. So, this setup is done only in the Consumer but in the their approach is duplicated among the Producers. Already happen to me to change the Queue name, Binding and Queue DLQ and Routing Key DLQ, and with the setup on Consumer I changed this in one unique place.
  3. If you would like to implement a DLQ, it's natural that the DLQ Listener will be in the Consumer, with the Binding of DLQ and Queue of DLQ there too. Does not make sense to me declare the DLQ Binding and DLQ Queue in each Producer.
  4. Every example with Async and Sync (RPC) communication in the RabbitMQ official documentation follow the pattern that I support. I could't find any statement about the setup differ from async to sync communication and the reasons for that change.
  5. The configuration is easier to understand, because the async and sync configuration follow the same idea: Binding and Queue on Consumer.

So, what is the recommended approach?

  • 3
    Nicely-written question. I hope there's someone here with enough experience in rabbitmq to answer it. – Robert Harvey Mar 3 '18 at 3:35
1

My team did a meeting to discuss this question. We understand that the Binding and Queue on Consumer is the better place. My question already presents the main advantages, so I will not copy in the answer here.

In the beginning of the meeting some team members "feel" that the right place was in the Producer when doing RPC calls. I understand that this feeling has a link with the fact that many developers think in a imperative way to do the things and, with this in mind, it's "strange" to put more logic on the Consumer instead of Producer.

So, does not matter if you are doing a RPC or asynchronous integration, the better place to put the Binding and Queue is in the Consumer.

  • 1
    +1 Always Consumer. Producer should not be aware of who will be consuming the messages being produced. Otherwise, every time you have a new consumer that need a new queue for the same message, you have to deploy the producer to create the queue. – bobek Jul 3 at 13:06

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.