Apache Kafka vs RabbitMQ
Compare Apache Kafka and RabbitMQ for retained events, work queues, routing, consumer progress, acknowledgement semantics and the cost of operating the chosen design.
Which pipeline approach fits?
Consider Kafka when retained event topics and independently progressing consumers fit the application. Consider RabbitMQ when its routing and selected queue or stream type fit the delivery requirement. RabbitMQ Streams also support retained, replay-oriented consumption, so queues versus replay is not a complete product comparison. Define retention, ordering, acknowledgement and application side effects before selecting a broker; no universal throughput winner is established here.
Seven differences that change the shortlist
| Buying question | Apache Kafka | RabbitMQ |
|---|---|---|
| Core choices | Partitioned event topics with configurable retention | Exchanges, queues and streams with distinct semantics |
| Consumer progress | Offsets and consumer arrangements for topic processing | Acknowledgements for queues; offsets and retention for streams |
| Replay | Read retained topic events again with the required consumer design | Use an appropriate stream when retained replay is required |
| Routing | Topic and partition design with application/connector choices | Exchange and binding routing for applicable queue workflows |
| Ordering | Specify partition, key and actual consumer behaviour | Specify queue/stream type, consumers and actual processing behaviour |
| Delivery safety | Review producer, consumer and destination behaviour together | Publisher confirms and consumer acknowledgements cover different stages |
| Operating cost | Brokers, retained replicas, network, processing and operator work | Nodes, selected destination types, retained replicas and operator work |
Four worked buying briefs
These are hypothetical scenarios with explicit assumptions. They do not establish equal capabilities, measured usability or a negotiated price.
| Requirement | Proposed exercise | Accept when |
|---|---|---|
| Work completion | Interrupt a permitted test worker around completion | Uncompleted work and repeat side effects are accounted for |
| Replay | Start an isolated consumer at an agreed historical position | Required retained events can be read |
| Delivery boundary | Trace publish, processing and acknowledgement separately | Each confirmation’s meaning is documented |
| Capacity | Model retained data and replicas over the required window | Storage and operating responsibility are explicit |
Order work queue
Can workers handle one task without losing an uncompleted delivery?
Apache Kafka: Define the consumer arrangement, progress tracking and retry strategy.
RabbitMQ: Define the queue type, manual acknowledgement and retry handling.
Use synthetic work with an idempotency key; the business side effect must be safe to repeat.
Second consumer
Can a new application read the retained event history?
Apache Kafka: Define the independent consumer and starting offsets within retention.
RabbitMQ: Use a supported stream and define its offset and retention policy.
Do not promise historical replay from a queue whose messages have already been acknowledged and removed.
Failed acknowledgement
What happens if a worker commits output and then disconnects?
Apache Kafka: Review the offset commit and destination transaction boundary.
RabbitMQ: Review acknowledgement timing and expected redelivery.
A repeated message must not create an unintended second business action.
Growing retention
Can the team retain the required history without exhausting capacity?
Apache Kafka: Estimate partitions, replication, retained data and transfer.
RabbitMQ: Estimate the selected queues or streams, replicas and retention.
Measure capacity in the actual design; this comparison contains no synthetic throughput ranking.
Specify the destination type
Kafka’s retained topics and RabbitMQ’s queue and stream options make the real decision more specific than two product names. Acknowledged queue messages and retained stream events have different lifecycles. Pick the required behaviour for each destination rather than assuming one setting describes an entire broker.
For ordering, describe the key or partition, consumer concurrency and the point when processing finishes. An ordered delivery path does not establish that parallel workers complete business actions in the same order. Put the expected application result into the evaluation contract.
A broker acknowledgement is not the whole transaction
RabbitMQ distinguishes publisher confirms from consumer acknowledgements. One concerns the publisher’s interaction with the broker; the other concerns delivery to the consumer. Kafka also requires an explicit design for producer behaviour, consumer progress and destination writes. Inspect the full chain before describing a business operation as exactly once.
Rehearse the difficult boundary: output is committed but consumer progress is not. Use an isolated synthetic workload and identify how the next delivery is handled. Budget retained data, replicas, network traffic and recovery ownership in addition to normal message volume, whether self-managed or purchased as a managed service.
Questions before you choose
Is RabbitMQ limited to ordinary work queues?
No. RabbitMQ also supports streams with retained, replay-oriented consumption. Compare the actual queue or stream type.
Do publisher confirms prove the application processed a message?
No. In RabbitMQ, publisher confirms and consumer acknowledgements cover different parts of the delivery chain.
Which broker has higher throughput?
No measured throughput conclusion is made here. Evaluate the same durability, retention, message size, client and failure requirements on the intended infrastructure.
Your practical evaluation pack
Download the pipeline checklist (CSV)
Four proposed checks with blank evidence and owner columns. Record the actual deployment, package, data volume and recovery requirements in your evaluation.
Turn the comparison into your own evaluation
Use the same criteria and priorities for both products, keep unknowns unassessed and record the plan and evidence behind your ratings.
Build a Apache Kafka vs RabbitMQ scorecard →Keep the assumptions with the figures
Use the date, billing cycle, units and limits with each example. Check current account terms before purchasing. Unverified prices and model costs stay unpriced.
Download the buying examples as JSON ↓Share the comparison
Use these examples when discussing the shortlist with your team.