A standard example uses a topic exchange for logging. A topic exchange will deliver messages to every queue with a pattern matched routing key.

For example, you can bind three queues with routing keys where:

queue A = citical.log

queue B = warn.log

queue C = * .log

(Note that there should be no space after the wildcard) Then, when you publish a message to that exchange with the key "warn.log" it be delivered to queue B and C but not queue A. This is nice because you could have queue A sending you texts, calls, emails, bike messengers, etc when it gets a message; queue B just an email; and queue C just logging. Now, you're easily getting logging messages where they should go, at the same time.

Even better: let's say you want to add in a metrics system based on your logs. It's dead simple to tap into that log feed and get all of your log messages to process. Just add a new queue:

queue D = * .log

Now your new queue is getting copies of all of those tasty log messages as well.

Another quick example: at Updox we have an API that partners can call to send faxes. Part of this process involves converting the faxes to images for the user to view, building thumbnails, or otherwise heavy processing tasks.

Now, for scalability we could load balance more and more full blown web servers, OR we could pass the heavy processing tasks off to a Rabbitmq exchange and have a processing engine pickup those messages and process them. If we do the latter, then to scale we can just add another processing engine and tell it to listen to the exchange! As we grow, we can add as many processing engines as we need!

I think the question really is, what can't you use Rabbit for?

We use rabbitmq to send push notifications to clients, rabbit has a stomp plugin that can accept web socket connections see http://www.rabbitmq.com/blog/2012/05/14/introducing-rabbitmq...

Lets say you have metrics for certain aspects of your system that you're trying to monitor. When they cross a certain threshold you could have a notification sent out.