rabbitmq-exchange

I'm a little confused. I'm trying to implement topic exchanges and am not sure what is needed. I want to have several routing keys and 1 topic exchange (the default amq.topic). My keys would be like: customer.appA.created customer.appB.created customer.*.created I want my queue(s) to be durable, but do I need 1 'customer' queue or 2 queues for appA and appB? I have my publisher figured out; connect, exchange declare, basic publish . But I'm struggling with the consumers. Let's say I want to open 3 consoles, one for each of the aforementioned routing keys. My current consumer has: connect,

It seems like the worker pattern, fanout, and filtered topics can all be implemented with topic exchanges. Why would I ever use a direct or fanout exchange instead? We would like to codify common patterns found in our org in a library that abstracts the infinite flexibility of amqp (naming conventions, defaulting to durable, sending common headers, expirations etc.). Should we leverage the different exchange types or implement all patterns with topics; why? (We have consumers/publishers in Java via spring boot, in golang, and in php) Why shouldn't I use rabbitmq topic exchanges for everything?

We've got an application which will be using RabbitMQ and have several different queues for passing messages between tiers. Initially, I was planning to use multiple direct exchanges, with one for each message type, but it looks like having a single topic exchange with queues using different routing key bindings will achieve the same thing. Having a single exchange also seems like it would be a bit easier to maintain, but I was wondering if there is any benefit (if any) of doing it one way over the other? Option 1, using multiple direct exchanges: ExchangeA (type: direct) -QueueA ExchangeB

I`ve been reading about the principles of AMQP messaging confirms. ( https://www.rabbitmq.com/confirms.html ). Really helpful and wel written article but one particular thing about consumer aknowledgments is really confusing, here is the quote: Another things that's important to consider when using automatic acknowledgement mode is that of consumer overload . Consumer overload? Message queue is processed and kept in RAM by broker (if I understand it correctly). What overload is it about? Does consumer have some kind of second queue? Another part of that article is even more confusing:

I have planned to delay the processing of messages in queue by following these two links link1 link2 . So, as suggested in the link. I have declared the original queue with the x-dead-letter-exchange and x-dead-letter-routing-key args. Which published the messages to the so called dead-letter-queue when message either failed to get processed by consumer or ttl happen or queue length exceed. Now in the dead-letter-queue similar args have been set along with the ttl parameter. Which is suppose to republish the messages to the original queue after ttl exceed. But the problem is it is dropping all