A short while back I wrote a piece, Why Message Queues Suck. The gist of the piece is that for the same labor and overhead required to implement and maintain an inter-service notification architecture using message queues, you can just as easily implement inter-service notification by Direct To Endpoint communication. (Please see Figure 1 below.)
As you might imagine, the piece caused quite a stir, particularly on Reddit.
The word around the water cooler is that a queue has yet to be created that I don’t like. Whether it’s RabbitMQ, AWS SNS/SQS, or Google Cloud Pub-Sub, regardless of the implementation, I love queues to death, gobble, gobble…I’ll eat ‘em up. I mean, what’s not to like?
Not too long ago at a due diligence review, I was presenting my idea for a mission-critical enterprise architecture.
Anypoint Platform is fast. The legacy systems that it often connects to? Not so much.
Therefore, in real world use cases, the requirements often call for limiting the message throughput to protect the endpoint systems from being overwhelmed by traffic. Architectural designs that support message throttling commonly incorporate some elements of message queues to stage and hold messages in-flight, so that the endpoints can process them at a steadier pace.
MuleSoft provides the most widely used integration platform for connecting any application, data source or API, whether in the cloud or on-premises. With Anypoint Platform®, MuleSoft delivers a complete integration experience built on proven open source technology, eliminating the pain and cost of point-to-point integration. Anypoint Platform includes CloudHub™ iPaaS, Mule ESB™, and a unified solution for API management™, design and publishing.