0% completed
RabbitMQ vs. Kafka vs. ActiveMQ
On This Page
Key Differences
How to Choose
Quick Reference
Conclusion
RabbitMQ, Kafka, and ActiveMQ are the three message brokers you will hear about most often. All three move messages between producers and consumers, but they are built on very different ideas. Here is each one in a single sentence:
- RabbitMQ: a smart broker that routes each message through exchanges into queues, and deletes the message once a consumer acknowledges it.
- Kafka: a distributed append-only log that keeps messages after delivery, so consumers pull at their own pace and can replay history.
- ActiveMQ: a classic JMS broker (JMS is the standard Java messaging API) that offers both queues and topics and speaks many protocols.
Key Differences
| Dimension | RabbitMQ | Kafka | ActiveMQ |
|---|---|---|---|
| Architecture | Smart broker, dumb consumer. Routes via exchanges and queues. | Distributed commit log. Dumb broker, smart consumer. | Classic JMS broker with queues and topics. |
| Built on | Erlang | Scala and Java (JVM) | Java (JVM) |
| Message model | Queue based. Exchanges route to queues. | Append only log. Topics split into partitions. | JMS queues (point to point) and topics (pub/sub). |
| Protocol support | AMQP 0.9.1, MQTT, STOMP, HTTP | Custom Kafka binary protocol over TCP | OpenWire, AMQP, MQTT, STOMP, JMS |
| Throughput | Tens of thousands of messages per second per node. | Millions of messages per second across a cluster. | Tens of thousands per second. Artemis scales higher. |
| Latency | Very low. Microseconds to low milliseconds. | Low. Optimized for throughput over latency. | Low milliseconds. |
| Message retention | Deleted once acknowledged. | Kept for a configurable time or size, even after consumption. | Deleted once acknowledged. |
| Replay | Not natively supported. | First class. Consumers reset offsets to replay. | Limited. Some support via message stores. |
| Ordering | Per queue, with single consumer. | Strict per partition. | Per queue. Message groups for finer control. |
| Consumer model | Push based. Broker delivers to consumers. | Pull based. Consumers fetch at their own pace. | Push based. Pull also supported. |
| Routing | Rich. Direct, topic, fanout, headers exchanges. | Minimal. Partition key on producer side. | Selectors, virtual topics, composite destinations. |
| Scalability | Vertical first. Clustering and quorum queues for HA. | Horizontal. Built for distributed scale. | Vertical first. Network of brokers for federation. |
| Delivery guarantees | At most once, at least once. | At most once, at least once, exactly once with transactions. | At most once, at least once, exactly once. |
| Best for | Task queues, RPC, complex routing, microservice messaging. | Event streaming, log aggregation, analytics pipelines, event sourcing. | Enterprise integration, legacy JMS apps, hybrid messaging. |
| Weak spot | Slows when queues grow very large. | Heavier ops. Overkill for simple task queues. | Lower throughput than Kafka. Less momentum than RabbitMQ. |
One term in the table deserves a quick definition. A consumer's current position in a Kafka log is called its offset. Resetting the offset moves the consumer back in the log, so it can read old messages again.
How to Choose
Ask three questions, in order:
- Do you need to replay events, keep history, or stream huge volumes of data? If yes, use Kafka. Its append-only log keeps messages after delivery, and nothing else matches its throughput at scale.
- Do you need flexible per-message routing or classic task queues? If yes, use RabbitMQ. Its exchanges route messages by rules, and its latency is excellent for job dispatch and RPC.
- Are you integrating with enterprise Java or existing JMS applications? Use ActiveMQ. It speaks JMS natively and fits legacy enterprise stacks with the least friction.
💡 In a system design interview, do not just name a broker. Tie it to the workload. "Click events must be stored and replayable for analytics, so I would pick Kafka." Or: "Order processing needs per-task routing with retries and low latency, so RabbitMQ fits better." Naming the trade-off is what earns the credit.
Quick Reference
-
RabbitMQ
- Model: smart broker routes messages through exchanges into queues
- Retention: message deleted once acknowledged
- Delivery: push based, very low latency
- Use it for: task queues, RPC, complex routing, microservice messaging
-
Kafka
- Model: append-only log, topics split into partitions
- Retention: messages kept for a configured time or size, replay supported
- Delivery: pull based, built for massive throughput
- Use it for: event streaming, log aggregation, analytics pipelines, event sourcing
-
ActiveMQ
- Model: JMS queues and topics in one broker
- Retention: message deleted once acknowledged
- Delivery: push based, pull also supported
- Use it for: enterprise integration and legacy JMS applications
Conclusion
A quick way to remember it: RabbitMQ is the smart router for traditional messaging, Kafka is the durable log built for streaming and replay, and ActiveMQ is the JMS workhorse for enterprise Java systems. Whichever you pick, it still has to grow with your traffic. The final lesson, Scalability and Performance, shows the techniques that make that possible.
Mini Walia
· 2 years ago
Can you add feature comparison table of different distribution systems ?
On This Page
Key Differences
How to Choose
Quick Reference
Conclusion