Can somebody explain me in what use-cases I should consider using AMQP like e.g. RabbitMQ? What are the pros and cons?


2 Answers 2


Imagine that you have a web service that can accept many requests per second. You also have a accounting system that does a lot of things, one of which is processing the requests coming from the web service.

If you put a queue between the web service and the accounting system, you will be able to:

  • have less coupling between the two applications, because now both applications have to know the configuration parameters of the queue management system and the name of the queue. Here the catch is that usually you are more likely to move to another server some application than move the queue management system
  • if you have a lot of requests coming in a short amount of time, the accounting system will be able to process them all anyway
  • persist some requests if their number becomes really huge

Of course, you could have more complex situations where the number of your applications is much bigger than two and you need to manage the communication between them.

  • 1
    1) How is A coupled to B better than A coupled to C and C coupled to B?
    – Charlie
    Aug 28, 2013 at 18:59
  • 2) Why not put the queue into the accounting system? Why introduce a new moving black-box part that needs additional configuration?
    – Charlie
    Aug 28, 2013 at 19:00
  • 2
    @Charlie about question 1, I have modified my answer. About question 2, what exactly do you mean by putting the queue into the accounting system? You want to use a queue data structure? In that case you will have more code to write to persist it. You want to simulate the queue using a database table? Again you will have to write some good code to manage that table. Something else that I did not thought about? Aug 28, 2013 at 19:23
  • I misspoke for 1. If the queue is placed in the web service or the queue is placed in the application, then one coupling remains. If, however, the queue is external to both, you now have twice the coupling, and 50% more systems to manage/points of failure. If a third-party queue is selected, you will also have this new package to learn about and configure, and will likely be encumbered by countless features you have no interest in using, features that were added to make the queue general purpose and useful for many more situations than your own.
    – Charlie
    Sep 12, 2013 at 17:03
  • @Charlie, presumably a single message broker would be used among multiple systems. Or there would be a single proxy for the broker. (In our case, we are using a single Messaging appliance that can handle millions of messages per second for all of our systems). This actually creates greater decoupling because a message is generated by one system and any interested system can receive that message and perform appropriate logic. The only coupling is to the queue itself. Feb 27, 2014 at 15:12

In addition to providing a buffer between a web service and another backend service, message queues can be used for more advanced scenarios. Rabbit MQ (and other mature Message Queue products also referred to as MOM -- Message Oriented Middleware) can be configured to route and distribute messages according to different rules.

For example the Pub-Sub routing technique allows a single source to send a message and have many listeners receive it. This is commonly used by stock trading software to keep the users on the floor updated.

Also because of the fact that most MOMs have sdks for multiple languages and platforms, they can be used to integrate applications that are written on different platforms.

These are just a few of the scenarios enabled by MOMs.

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