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. You can also use a message queue to create loosely coupled systems.
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 standardization 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.
Do you want to send a comment or give me a hint about any issues with a blog post: Open up an issue on GitHub.
Do you want to fix an error or add a comment published on the blog? You can do a fork of this post and do a pull request on github.