Message-Oriented Middleware Systems: Technology Overview

We present a comprehensive characterization study of open-source message-oriented middleware (MOM) systems. We followed a rigorous methodology to select and study ten popular and diverse MOM systems. For each system, we examine 42 features with a total of 134 different options. We found that MOM systems have evolved to provide a framework for modern cloud applications through high flexibility and configurability and by offering core building blocks for complex applications including transaction support, active messaging, resource management, flow control, and native support for multi-tenancy. We also identify that there is an opportunity for the community to consolidate its efforts on fewer open-source projects. We have also created an annotated data set that makes it easy to verify our findings, which can also be used to help practitioners and developers understand and compare the features of different systems. For a wider impact, we make our data set publicly available.

💡 Research Summary

The paper presents a systematic, feature‑centric characterization of open‑source message‑oriented middleware (MOM) systems. Using the GitHub Search API, the authors first retrieved 57,768 repositories containing keywords such as “messaging”, “broker”, and “publish‑subscribe”. Applying a popularity filter of at least 300 stars reduced the pool to 375 projects. Manual inspection eliminated non‑general‑purpose tools, inactive repositories, and projects lacking sufficient English documentation, ultimately leaving 41 candidates. Further filtering removed libraries that only provide client‑side APIs (e.g., ZeroMQ) and specialized job‑scheduling systems, resulting in a final shortlist of ten widely used MOM platforms: Redis Streams, Redis PubSub, NSQ, Apache Kafka, RocketMQ, NATS Core, Apache Pulsar, RabbitMQ, EMQX, and Mosquitto. These systems span four dissemination topologies—single‑broker, peer‑to‑peer, mesh, and flexible—and are implemented in a variety of languages (C, Go, Java, Erlang, JavaScript) under permissive or Apache licenses.

For each system the authors examined 42 distinct functional categories, amounting to 134 configuration and deployment options. The investigation combined analysis of official design documents, user manuals, API specifications, developer blogs, forum posts, and, when necessary, source‑code inspection or direct deployment. The resulting taxonomy covers reliability, delivery semantics, ordering guarantees, transaction support, multi‑tenancy, resource‑management, flow‑control, active‑messaging, discovery services, and protocol support.

Key findings include:

1. Reliability and Replication – Almost all systems provide durable storage (disk‑based logs or databases) and replication mechanisms for high availability. Consistency models are predominantly eventual, with a minority offering strong consistency. Consumer state recovery after failures is widely supported.

2. Delivery Guarantees – The four classic semantics—best‑effort, at‑most‑once, at‑least‑once, and effectively‑once—are all represented. Kafka and Pulsar uniquely provide effectively‑once guarantees, which are critical for financial and audit‑heavy workloads.

3. Ordering Semantics – Two models were identified: path‑based ordering (messages retain order only when traversing the same network path) and multicast‑exchange ordering (strict in‑order delivery for all consumers of a multicast exchange). The latter is stronger but less common.

4. Transaction Support – Most systems allow multi‑topic transactions, though many implement non‑atomic variants. This capability enables complex business processes that span several queues or topics.

5. Multi‑Tenancy and Resource Management – Systems expose configurable limits on CPU, memory, network, and disk usage. Flow‑control is implemented via credit‑based or rate‑based schemes, providing isolation for tenants in shared deployments.

6. Active Messaging – Pulsar and ActiveMQ Artemis have introduced “function‑as‑a‑service” features, allowing user‑defined lambda‑style functions to be triggered on message arrival. This bridges MOM with stream‑processing and serverless paradigms but introduces new scheduling and isolation challenges.

7. Protocol Landscape – While standards such as MQTT, AMQP, and STOMP exist, the majority of the studied systems rely on custom protocols optimized for performance and feature richness. Only five of the ten systems support MQTT, underscoring limited standard adoption.

8. Configurability and Feature Overlap – The systems are highly configurable; Pulsar, RabbitMQ, and ActiveMQ Artemis expose the largest number of tunable parameters. Significant overlap exists across the ten platforms, suggesting duplicated effort within the open‑source community.

The authors argue that this redundancy presents an opportunity for consolidation: focusing community resources on a smaller set of mature projects could accelerate innovation, improve security hardening, and foster richer ecosystems. To support reproducibility and further research, they release an annotated dataset linking each observed characteristic to its source documentation (reference