They aren't a general solution and don't really add much to your average application. But there are still instances where they make a lot of sense.
What I would need to see required before bothering with a message queue architecture:
* High concurrency, atomic transactions
* Multiple stages of processing of a message required
* Traceability of process actions required
* Event triggers that will actually be used required
* Horizontal scaling actually the right choice
* Message queues can be the core architecture and not an add on to a Frankenstein API
Probably others, and yes you can achieve all of the above without message queues as the core architecture but the above is when I would think "I wonder if this system should be based on async message queues".
Could you elaborate a little on the traceability part, please? If the different steps of a processing chain are distributed via queues, you rather have an overhead in collecting the information in a central place, I would think.
That is certainly true, but message queues are pretty well suited to tagging and audit logs. So the systems involved tag the messages and an audit repository can accept logs from all services.
I guess this isn't in contrast to a monolith which is easier to log, but in contrast to non-message based microservices I think it's easier to implement the audit logging.
What I would need to see required before bothering with a message queue architecture:
* High concurrency, atomic transactions
* Multiple stages of processing of a message required
* Traceability of process actions required
* Event triggers that will actually be used required
* Horizontal scaling actually the right choice
* Message queues can be the core architecture and not an add on to a Frankenstein API
Probably others, and yes you can achieve all of the above without message queues as the core architecture but the above is when I would think "I wonder if this system should be based on async message queues".