Lakshya

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.

8 min read1 diagramAll 33 chapters

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.

ProductOwner, Sep 2026ModelLicenceGenuinely good atWatch for
IBM MQIBMQueue manager, with publish/subscribeCommercial; also as a serviceAssured delivery, XA, mainframe integration with CICS (the Customer Information Control System); near-universal in banksCost; specialist skills
Apache KafkaApache Software FoundationDistributed log; queue-style share groups since 4.2Open source (Apache 2.0)Throughput, replay, a vast connector ecosystemOperating it well is a discipline of its own
Confluent Platform and CloudIBM, since 17 Mar 2026Kafka distribution and managed serviceCommercialManaged Kafka, connectors, governance toolingUnit-based pricing that grows with use
Red Hat Streams for Apache KafkaRed Hat (IBM)Kafka on OpenShift, via the Strimzi operatorSubscriptionBanks standardised on OpenShiftTied to that platform
Cloud Kafka: Amazon MSK, Azure Event Hubs (Kafka API), Google’s managed KafkaAWS, Microsoft, GoogleManaged Kafka or Kafka-compatiblePay per useNo brokers to runCompatibility details differ by service
RabbitMQBroadcom (VMware Tanzu)Broker with flexible routing; quorum queues and streamsOpen source (Mozilla Public License 2.0); Tanzu RabbitMQ commercialRich routing, simple to startCommunity support policy since June 2024 (below)
Apache ActiveMQ (“Classic”)Apache Software FoundationJakarta Messaging (JMS) brokerOpen sourceEmbedded in countless applicationsAn older architecture
Apache ArtemisApache Software Foundation, its own project since Dec 2025High-performance broker for Jakarta Messaging (JMS) and the Advanced Message Queuing Protocol (AMQP); the base of Red Hat AMQ BrokerOpen source; Red Hat subscriptionA modern JMS broker with XAThe renaming confuses (below)
TIBCO EMS (Enterprise Message Service), Rendezvous, FTLCloud Software GroupJMS broker; low-latency busesCommercial, quote onlyLong history in integration and capital marketsOpaque pricing; private-equity ownership
Solace PubSub+SolaceEvent broker as hardware, software or cloud; an ‘event mesh’ across sitesCommercial; free Standard editionLow latency; trading-floor heritageSmaller ecosystem
Apache PulsarApache Software Foundation (StreamNative sells it)Log and queue, with storage separated into Apache BookKeeperOpen sourceMulti-tenancy, geo-replicationFar smaller adoption than Kafka
Cloud queues: Amazon SQS and SNS, Amazon MQ, Azure Service Bus, Google Pub/SubThe cloud providersManaged queues and topicsPay per request or per capacity unitZero operationsPortability; 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

THREE PRODUCTS, ONE IDEA — THREE COPIES, AND A WRITE COUNTS WHEN A MAJORITY HAS IT IBM MQ NATIVE HAactivereplicareplicaa majority of the three mustlog each write before it countsKAFKA PARTITIONleaderfollowerfolloweracks=all withmin.insync.replicas=2RABBITMQ QUORUM QUEUERaft leaderfollowerfollowerRaft consensus: committedonce a majority has it WHY THREE, NOT TWO. With two copies, a network split leaves each side unable to tell whether the other is dead or merely unreachable. With three, the side holding two is the majority and carries on; the side with one stops. Never two leaders — that rule is what makes “no acknowledged message is ever lost” true.
Modern brokers have converged on the same answer. Keep three copies, elect one leader, and confirm a write only when a majority holds it. The older IBM MQ options — a multi-instance pair on shared storage — rely on the storage to prevent two active queue managers instead.

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 exampleFigureWorking
Peak rate and size20,000 messages a second of 2 KBMeasured, plus growth
Ingress40 MB a second20,000 × 2 KB
Disk writes across the cluster120 MB a second× 3 for the replication factor
Kept for 7 daysabout 24 TB of data40 MB × 604,800 seconds
Stored with replicasabout 73 TB× 3
With 30–50% headroomroughly 95–110 TB of broker diskFor growth and rebalancing
Egress120 MB a secondThree 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 exampleFigureWorking
Peak rate and size2,000 persistent messages a second of 4 KBMeasured
Log writesabout 8 MB a second, each forced to diskThe recovery log is the bottleneck
Tolerated consumer outage30 minutesA business decision: how long may the core be down?
Messages to buffer3.6 million2,000 × 1,800 seconds
Queue space to bufferabout 14.4 GB3.6 million × 4 KB — set MAXDEPTH and disk to match
What happens beyond itProducers receive 2053, queue fullDecide deliberately: buffer longer, or push back on the channels

What to watch

ProductThe vital signs
IBM MQQueue depth and oldest-message age; channel status (running, retrying, stopped); dead-letter queue depth; log space; which applications have each queue open
KafkaConsumer 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
RabbitMQQueue 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

How does the market divide?Queue managers that forget once delivered, logs that remember, and managed cloud services sold per request or per capacity unit.
Who owns Confluent, RabbitMQ and TIBCO in 2026?IBM (since March 2026); Broadcom through VMware Tanzu; Cloud Software Group.
What is Cloud Software Group?The company formed when Vista Equity Partners and Evergreen Coast Capital bought Citrix (completed 30 Sep 2022, $16.5bn) and combined it with TIBCO.
What happened to ActiveMQ Artemis?It became Apache Artemis, a separate top-level Apache project, announced 3 December 2025; Red Hat AMQ Broker is built on it.
What changed in RabbitMQ 4.0?Released 18 September 2024: classic mirrored queues removed, quorum queues are the replicated type, and AMQP 1.0 became a core protocol.
What is the practical effect of Broadcom's RabbitMQ support policy?Stay on the newest release line, or buy a commercial licence to get patches for older lines.
Why do brokers keep three copies rather than two?With three, a network split leaves one side with a majority that can safely continue; with two, neither side can tell.
Size Kafka for 20,000 msg/s of 2 KB kept 7 days.40 MB/s ingress, about 24 TB of data, about 73 TB with three replicas, roughly 100 TB with headroom.
Why is the MQ log disk the key sizing input?Every persistent message is forced to the log before the put completes.
What is Kafka's single most important metric?Consumer lag.
What does a RabbitMQ memory alarm do?Blocks publishers to protect the broker — a slow consumer becomes a stalled producer.
Why is regional recovery never zero data loss?Cross-region replication is asynchronous, so the last seconds may be missing; reconciliation closes the gap.
← Real-time banking on messages: six flows, tracedMessaging licences, costs and the comparison →