Why Messaging Queues Might Not Suck

why messaging queues might not suck

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.

Why messaging queues suck


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.

JMS Queue: When Size Does Matter


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.