2 ms·

Not an expert in this domain, but off the top of my head: It's easier to handle certain situations, like if you have multiple recipients, you may want to notif

Not an expert in this domain, but off the top of my head: It's easier to handle certain situations, like if you have multiple recipients, you may want to notify all of them, at least one, at most one, etc. It's also a way of handling consumers that may be unavailable for whatever reason and your source may not want to have to deal with that. For example, if the producer is a cron job, you may not want it to have to hang around for an arbitrary time if your consumers are already busy. Sure, this means that the queue is available, but in principle it's supposed to be more available than the consumers.

brundolf 4y ago
Fair enough I guess, though in that case my mind goes to just having the recipient queue its own tasks internally and respond immediately, if the sender doesn't want to wait on it to finish
- nightpool 4y ago
  Which we know from the article that the recipient in this case was ALREADY doing. They were using RabbitMQ as a glorified cron job to poll the "status" of the other service every 5 minutes.
- vladvasiliu 4y ago
  Sure you can do that, but I'd say in the general case "it depends". If your needs are fairly basic, that's probably the best approach. You also eliminate some overhead (piping messages through a middle man, operating said middle man, etc.). But it's my understanding that if your needs are a bit more involved, the complexities of building a solid queue mean that it'll take time away from building your actual product. In that case, you may be better served by an off-the-shelf solution which already handles the corner cases and is good to go. I think this is the usual decision between using an external product and rolling your own.
- jojok 4y ago
  If there are multiple recipients then they may need to each maintain their own queues. But these queues may implicitly have an expectation of being in sync with each other. If you use a centralized message queue then there will be a single source of truth about what messages were received and in what order. This can help to avoid or debug problems that can arise if sender fails to send request to some receivers or if some receivers fail to process requests.

brundolf 4y ago

Fair enough I guess, though in that case my mind goes to just having the recipient queue its own tasks internally and respond immediately, if the sender doesn't want to wait on it to finish

nightpool 4y ago
Which we know from the article that the recipient in this case was ALREADY doing. They were using RabbitMQ as a glorified cron job to poll the "status" of the other service every 5 minutes.
vladvasiliu 4y ago
Sure you can do that, but I'd say in the general case "it depends". If your needs are fairly basic, that's probably the best approach. You also eliminate some overhead (piping messages through a middle man, operating said middle man, etc.). But it's my understanding that if your needs are a bit more involved, the complexities of building a solid queue mean that it'll take time away from building your actual product. In that case, you may be better served by an off-the-shelf solution which already handles the corner cases and is good to go. I think this is the usual decision between using an external product and rolling your own.
jojok 4y ago
If there are multiple recipients then they may need to each maintain their own queues. But these queues may implicitly have an expectation of being in sync with each other. If you use a centralized message queue then there will be a single source of truth about what messages were received and in what order. This can help to avoid or debug problems that can arise if sender fails to send request to some receivers or if some receivers fail to process requests.