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 spec

Answer 1

This answer echoes the previousone and if you refer to this page, I believe you'll that one particular use case described is:

Direct exchanges are often used to distribute tasks between multiple workers (instances of the same application) in a round robin manner.

Answer 2

Do you mean a fanout exchange or a topic exchange? a fanout exchange is very different from a direct exchange. I presume that sending the photo to the exchange is sent with a routing key that specifies that there is a photo. In which case you have a consumer that generates the thumbnail and when you want to add a new consumer you can just add it and get the same message but do something different with it, ie award points.

The use case holds up. I think the point is that the exchange is originally created as a direct exchange.

Answer 3

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.