Infrastructure & Reliability · Middleware — Messaging · Chapter 28 of 33
The broker market: products, clouds, and the infrastructure under them
IBM MQ, Kafka and its distributions, RabbitMQ, the two ActiveMQs, TIBCO, Solace, Pulsar and the cloud queues — who owns what in 2026, what each is genuinely for, and how to size and run one in production.
The market divides cleanly once you apply the distinction from the last chapter but one: queue managers that hand each message to a consumer and forget it, logs that remember, and managed cloud services that sell either one by the request. Ownership has also changed more in the last four years than in the previous twenty, so the table records who owns what as of September 2026.
| Product | Owner, Sep 2026 | Model | Licence | Genuinely good at | Watch for |
|---|---|---|---|---|---|
| IBM MQ | IBM | Queue manager, with publish/subscribe | Commercial; also as a service | Assured delivery, XA, mainframe integration with CICS (the Customer Information Control System); near-universal in banks | Cost; specialist skills |
| Apache Kafka | Apache Software Foundation | Distributed log; queue-style share groups since 4.2 | Open source (Apache 2.0) | Throughput, replay, a vast connector ecosystem | Operating it well is a discipline of its own |
| Confluent Platform and Cloud | IBM, since 17 Mar 2026 | Kafka distribution and managed service | Commercial | Managed Kafka, connectors, governance tooling | Unit-based pricing that grows with use |
| Red Hat Streams for Apache Kafka | Red Hat (IBM) | Kafka on OpenShift, via the Strimzi operator | Subscription | Banks standardised on OpenShift | Tied to that platform |
| Cloud Kafka: Amazon MSK, Azure Event Hubs (Kafka API), Google’s managed Kafka | AWS, Microsoft, Google | Managed Kafka or Kafka-compatible | Pay per use | No brokers to run | Compatibility details differ by service |
| RabbitMQ | Broadcom (VMware Tanzu) | Broker with flexible routing; quorum queues and streams | Open source (Mozilla Public License 2.0); Tanzu RabbitMQ commercial | Rich routing, simple to start | Community support policy since June 2024 (below) |
| Apache ActiveMQ (“Classic”) | Apache Software Foundation | Jakarta Messaging (JMS) broker | Open source | Embedded in countless applications | An older architecture |
| Apache Artemis | Apache Software Foundation, its own project since Dec 2025 | High-performance broker for Jakarta Messaging (JMS) and the Advanced Message Queuing Protocol (AMQP); the base of Red Hat AMQ Broker | Open source; Red Hat subscription | A modern JMS broker with XA | The renaming confuses (below) |
| TIBCO EMS (Enterprise Message Service), Rendezvous, FTL | Cloud Software Group | JMS broker; low-latency buses | Commercial, quote only | Long history in integration and capital markets | Opaque pricing; private-equity ownership |
| Solace PubSub+ | Solace | Event broker as hardware, software or cloud; an ‘event mesh’ across sites | Commercial; free Standard edition | Low latency; trading-floor heritage | Smaller ecosystem |
| Apache Pulsar | Apache Software Foundation (StreamNative sells it) | Log and queue, with storage separated into Apache BookKeeper | Open source | Multi-tenancy, geo-replication | Far smaller adoption than Kafka |
| Cloud queues: Amazon SQS and SNS, Amazon MQ, Azure Service Bus, Google Pub/Sub | The cloud providers | Managed queues and topics | Pay per request or per capacity unit | Zero operations | Portability; per-request cost at high volume |
Two ownership facts to have ready. Cloud Software Group is the company formed when the private-equity firms Vista Equity Partners and Evergreen Coast Capital completed their purchase of Citrix on 30 September 2022, valued at $16.5 billion, and combined it with TIBCO. And IBM now owns IBM MQ, Red Hat’s messaging products and Confluent — more of a bank’s messaging estate than any vendor has before.
“Which ActiveMQ?”
Apache ActiveMQ used to contain two brokers: the original, now called ActiveMQ Classic, and a newer, faster one called ActiveMQ Artemis. In November 2025 the project voted to split them, and on 3 December 2025 the Apache Software Foundation announced Apache Artemis as a top-level project in its own right. Red Hat’s AMQ Broker is built on Artemis.
So when someone says “we run ActiveMQ”, ask which — the two differ in architecture, performance and failure behaviour, and the old names will linger in documentation for years.
RabbitMQ’s support policy, in one paragraph
RabbitMQ’s code remains open source. But Broadcom’s documentation states that from 1 June 2024, community support for the 3.13 series was limited to regular contributors and holders of a commercial licence, and that patches for release lines past their end of community support go only to commercial customers. In practice: stay on the newest release line, or pay. RabbitMQ 4.0, released on 18 September 2024, also removed the old classic mirrored queues after three years of deprecation — replicated queues are now quorum queues, so any upgrade from 3.x is a migration of every replicated queue.
High availability: one idea in three products
Sizing from four numbers
Every messaging capacity plan starts from the same four inputs: messages per second at peak, message size, whether messages are persistent, and how long they must be kept — a retention period for a log, a tolerated outage for a queue.
| Kafka worked example | Figure | Working |
|---|---|---|
| Peak rate and size | 20,000 messages a second of 2 KB | Measured, plus growth |
| Ingress | 40 MB a second | 20,000 × 2 KB |
| Disk writes across the cluster | 120 MB a second | × 3 for the replication factor |
| Kept for 7 days | about 24 TB of data | 40 MB × 604,800 seconds |
| Stored with replicas | about 73 TB | × 3 |
| With 30–50% headroom | roughly 95–110 TB of broker disk | For growth and rebalancing |
| Egress | 120 MB a second | Three consumer groups each reading everything |
Kafka’s tiered storage, which moves older data to object storage so broker disks hold only the recent part of the log, changes the disk line dramatically; see streaming internals.
| IBM MQ worked example | Figure | Working |
|---|---|---|
| Peak rate and size | 2,000 persistent messages a second of 4 KB | Measured |
| Log writes | about 8 MB a second, each forced to disk | The recovery log is the bottleneck |
| Tolerated consumer outage | 30 minutes | A business decision: how long may the core be down? |
| Messages to buffer | 3.6 million | 2,000 × 1,800 seconds |
| Queue space to buffer | about 14.4 GB | 3.6 million × 4 KB — set MAXDEPTH and disk to match |
| What happens beyond it | Producers receive 2053, queue full | Decide deliberately: buffer longer, or push back on the channels |
What to watch
| Product | The vital signs |
|---|---|
| IBM MQ | Queue depth and oldest-message age; channel status (running, retrying, stopped); dead-letter queue depth; log space; which applications have each queue open |
| Kafka | Consumer lag — how far each group is behind the newest message, the single most important Kafka metric; under-replicated partitions; in-sync replica changes; request latency; disk |
| RabbitMQ | Queue length and unacknowledged messages; memory and disk alarms, which make RabbitMQ block publishers to protect itself — the moment a slow consumer becomes a stalled producer |
Disaster recovery
Within a site or across nearby zones, the majority rule above gives no data loss. Across distant regions it cannot, because waiting for a far-away majority on every write is too slow. Every product therefore replicates to a second region asynchronously — IBM MQ’s Cross-Region Replication for Native HA, disaster-recovery configurations of RDQM (the Replicated Data Queue Manager), Kafka’s MirrorMaker 2 or Confluent’s cluster linking, RabbitMQ’s federation and shovel plug-ins — and accepts that the last few seconds of messages may be missing after a regional failover. The recovery point objective for regional loss is therefore never zero, and the reconciliation process in the flows chapter is what closes the gap.
Check yourself