> For the complete documentation index, see [llms.txt](https://stephen-tsoi.gitbook.io/stephen-tsoi-docs/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://stephen-tsoi.gitbook.io/stephen-tsoi-docs/messaging-technology/messaging-bus-comparison-series.md). # Messaging Bus Comparison Series A 20-part master comparison index evaluating 10 leading messaging platforms across critical architectural dimensions like push-pull mechanics, KRaft, and OpenTelemetry. ### Introduction & Push vs Pull #### Why I'm Starting This Series Over the last few months, I've been researching the most popular messaging platforms used in modern enterprises, event-driven architectures, and cloud-native environments. As part of this research, I'm comparing 10 leading messaging products: * ActiveMQ * AWS SQS * Azure Queue Storage * Azure Service Bus * EMQX * IBM MQ * Kafka * RabbitMQ * Solace PubSub+ * TIBCO EMS Before finalizing the content, I'd like to validate the findings with the community and learn from practitioners with hands-on experience. The objective of this series is simple: > Publish the research incrementally, gather feedback, challenge assumptions, and improve the accuracy of the final reference. ### What Will Be Covered in This Series? Over the next 17 editions, I'll compare these products across the following areas: 1. Push vs Pull 2. Point-to-Point vs Pub/Sub 3. Persistent vs Non-Persistent Messaging 4. Delay Queue 5. Dead Message Queue (DMQ) 6. Last Value Queue (LVQ) 7. Supported Protocols 8. Security Control 9. Certification 10. Authentication 11. Authorization 12. ACL Support 13. Queue Ownership 14. Kafka ZooKeeper vs KRaft 15. Scalability 16. Message Acknowledgement 17. OpenTelemetry (OTel) Support ### Community Review Requested I'd appreciate feedback from architects, developers, operators, and platform engineers. * Is anything inaccurate or outdated? * What important considerations are missing? * Are there vendor-specific exceptions? * Which entries would you change based on real-world experience? ### My Initial Observation Most traditional message brokers favor push-based delivery, while event-streaming platforms such as Kafka are primarily pull-based. Several products support both models depending on protocol, SDK, or deployment pattern. Do you agree with this assessment? --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` GET https://stephen-tsoi.gitbook.io/stephen-tsoi-docs/messaging-technology/messaging-bus-comparison-series.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `build a script that syncs our docs to a CMS` lets GitBook tailor the answer to that use case. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.