For many systems there isn’t a need for message queues. Regular HTTP-style request/response are often enough. If your system is architected without thinking about events you might have very little need for it.
A webhook can be good enough. It all depends on your architecture and business scenarios if it makes sense.
A message queue is good for dealing with asynchronous messages not expected to be dealt with immediately. A message queue does not work well for request/response scenarios.
One of the neat things with having a properly architected publish/subscribe is that you can decouple parts of your system. You can for instance use message systems with routing in order to have many consumers for selected messages or events. Products that fit the bill are:
ZeroMQ looks particularly interesting as it doesn’t require a dedicated deployment. Though I’ve never used it.
The assumption is that some systems are not interested in receiving some events. We see that eShopOnContainers can use both RabbitMQ and Azure Service bus.
I’ve found that RabbitMQ style communication can be useful for dealing with longer running tasks generated by user input (not to be confused by cron-jobs). It’s a known type of technology that has been around. Note for instance some of the standardisation around AMQP.
If pushing a huge number of messages/events then routing might be less of a concern why you might want to look into systems like:
Kafka has gotten a lot of attention in recent years and is probably still considered hot to work with.
We might not need message queues for all systems and services, but they can be useful tools for certain use cases. You also need to decide on what style of message queues you need for your system.
Comments or errors? Fork this post and do a pull request on github