Teams choosing an open messaging target often start by comparing broker features, throughput numbers, protocol support, connector counts, and pick the one that looks most capable. That comparison skips the decision that actually matters: which delivery model your workload belongs to. A distributed log and a smart message queue are genuinely different systems, and picking the wrong family is far more expensive than picking a less feature-rich member of the right one. This guide is a rubric for classifying your workload first, then matching it, and for being honest that some source semantics do not map one-for-one.
Start with the delivery model, not the broker
Before you shortlist Kafka or RabbitMQ, decide which model each workload really is. A log keeps an ordered, replayable record of events and lets consumers track their own position, which suits streaming, event pipelines, and replay. A smart broker holds state, routes each message, and tracks acknowledgements, which suits queueing, request-reply, and work distribution. Then write down, per workload, your ordering guarantees, durability and transaction requirements, peak throughput, and the protocol your clients speak (AMQP, the Kafka protocol, JMS). Those inputs decide the target; the feature grids do not.
What separates one broker family from another
- Delivery model. This is the deciding split. A source built on one model does not map cleanly onto the other: strict ordering, transactions, and JMS selectors that feel free on a broker take deliberate design on a log, and high fan-out replay that is natural on a log is awkward on a broker. A mixed estate is split by pattern, not forced onto one target.
- Ordering, durability, and transactions. Reproduce the source’s guarantees deliberately rather than assuming they carry over. Durable queues, persistent messages, publisher confirms, and manual acks are choices you make on the target, and the semantics you need constrain which family fits.
- Throughput. High-throughput streaming and log or event pipelines point one direction; moderate-rate queueing and routing point another. Size on peak throughput, and remember self-hosting shifts cost from license to compute and operations.
- Protocol. AMQP clients, Kafka-protocol clients, and JMS applications each favor different targets and different migration paths. A protocol-compatible target can turn client migration into a config change instead of a rewrite.
- Operational maturity. Be honest about what your team can run. A lightweight system is cheaper to operate than a full streaming platform, and the right choice weighs the operations you take on, not only the feature list.
Which broker fits which workload
Classify each workload, then match it. High-throughput streaming and log or event pipelines land on Kafka, and a move off Confluent lands here too because Confluent is Kafka at the core, so clients usually only change bootstrap servers and security settings. Classic queueing and routing, task and work-queue patterns over AMQP, land on RabbitMQ, and IBM MQ, TIBCO EMS, and Solace queue workloads map here, with JMS apps often taking the shorter path through RabbitMQ’s JMS client before any deeper refactor. Lightweight, low-latency pub/sub and request-reply point to NATS. Where you want Kafka-API compatibility with different operational tradeoffs, Pulsar and Redpanda are the options to weigh. The point is that the right target falls out of the delivery model, not out of any broker’s throughput headline.
Where workloads land on the wrong family
The costly mistake is forcing a workload onto the wrong family, putting a stateful, ordered, transactional queue workload onto a log because the log benchmarks faster, then rebuilding ordering and acknowledgement semantics by hand. Close behind is assuming delivery guarantees carry over, and discovering after cutover that messages you thought were durable were not. A third is treating a broker-to-broker move like the near-config-change of a Confluent-to-Kafka move; leaving IBM MQ, EMS, or Solace asks real work of the applications. The fourth is retiring the source before every consumer has moved, since a consumer that quietly stayed behind is the classic way to strand messages.
Test on one topic before you trust it
Turn your top candidate into a proof on a single non-critical topic or queue before committing the estate. Stand up the target, recreate topics or queues and ACLs, and bridge during transition so the producer cutover is decoupled from the consumer cutover and you are never mid-flight with a half-migrated flow. Benchmark throughput and latency, run delivery-semantics and ordering tests, exercise consumer failover and replay, and soak under backpressure, with the acceptance bar set at no message loss and semantics preserved under load. Repoint producers first and consumers second, a topic or queue family at a time, draining backlogs to zero before cutting over, and reconcile the client inventory before retiring anything. Keep the bridge running until parity holds, and use the TCO calculator to model the per-core comparison, treating the figures as illustrative until sized against your own throughput.