When to use direct exchange over fanout exchange

Question

As far as I can tell, there is no proper use case for a direct exchange, as anything you can do with it you can do with a fanout exchange, only more expandably.

More specifically, in reading RabbitMQ in Action, the authors numerously refer to the use case that goes something like - "Suppose when a user uploads a picture you need to generate a thumbnail. But then later marketing also tells you to award points for uploading a photo. With RabbitMQ you just have to create another queue and do no work on the producer side!"

But that's only true if you've had the foresight to create a fanout exchange on the producer side. To my understanding a direct exchange cannot accomplish this and is only appropriate when you actually want tight coupling between exchange and queue, (which you don't, because that's the point of messaging systems.)

Is this correct or is there an actual use case?

Answer 1

Compared to the fanout exchange, the direct exchange allows some filtering based on the message's routing key to determine which queue(s) receive(s) the message. With a fanout exchange, there is no such filtering and all messages go to all bound queues.

So if you have a direct exchange with several queues bound with the same routing key, and all messages have this key, then you have the same behavior as the fanout exchange. This is better explained in tutorial 4 on the RabbitMQ website.

In the image upload use case, you can use:

• a fanout exchange with two queues (one for the thumbnail worker, one for the score computation worker). The routing key is ignored.

  fanout-exchange
  |--> queue --> thumbnail-worker
  `--> queue --> score-worker
  

• a direct exchange with again two queues. Queues are bound with the image-processing key for instance, and messages with this key will be queued to both queues.

  direct-exchange
  |--["image-processing"]--> queue --> thumbnail-worker
  `--["image-processing"]--> queue --> score-worker
  

  Of course, in this situation, if the message's routing key doesn't match the binding key, none of the queues will receive the message.

You can't put the two workers on the same queue, because messages will be load balanced between them: one worker will see half of the messages.