Question

On my team at work, we use the IBM MQ technology a lot for cross-application communication. I’ve seen lately on Hacker News and other places about other MQ technologies like RabbitMQ. I have a basic understanding of what it is (a commonly checked area to put and get messages), but what I want to know what exactly is it good at? How will I know where I want to use it and when? Why not just stick with more rudimentary forms of interprocess messaging?

Answer 1

All the explanations so far are accurate and to the point – but might be missing something: one of the main benefits of message queueing: resilience.

Imagine this: you need to communicate with two or three other systems. A common approach these days will be web services which is fine if you need an answers right away.

However: web services can be down and not available – what do you do then? Putting your message into a message queue (which has a component on your machine/server, too) typically will work in this scenario – your message just doesn’t get delivered and thus processed right now – but it will later on, when the other side of the service comes back online.

So in many cases, using message queues to connect disparate systems is a more reliable, more robust way of sending messages back and forth. It doesn’t work well for everything (if you want to know the current stock price for MSFT, putting that request into a queue might not be the best of ideas) – but in lots of cases, like putting an order into your supplier’s message queue, it works really well and can help ease some of the reliability issues with other technologies.