NexisyTech Learningby Nexisy Technologies

Message Brokers: RabbitMQ vs Kafka vs ActiveMQ

Queues and logs for decoupling services — and how the three popular brokers differ.

Intermediate10 min read3 interview questions

A message broker lets services communicate without calling each other directly. The producer hands a message to the broker and moves on; consumers process it when they are ready.

Brokers fall into two families. Queue brokers (RabbitMQ, ActiveMQ) deliver each message to a consumer and delete it once acknowledged. Log-based platforms (Kafka) append events to a durable, replayable log that many consumer groups read at their own pace.

Diagram

Queue (RabbitMQ, ActiveMQ)Log (Kafka)ProducerExchangeroutes by keyQueueWorker 1Worker 2ProducerTopic partitionsappend-only, retainedGroup: billingoffset 1042Group: BIoffset 87
A queue hands each message to one worker; a log keeps events so each consumer group reads at its own offset.

Key concepts

RabbitMQ
AMQP broker with flexible routing (direct, topic, fanout exchanges), per-message acknowledgements and priorities. Great for task queues and RPC-style work.
Apache Kafka
Distributed commit log with partitions, high throughput and long retention. Consumers track offsets and can replay history. Great for event streaming and analytics.
ActiveMQ
Java-based broker supporting JMS, AMQP, STOMP and MQTT. Common in enterprise Java integration.
Delivery guarantees
At-most-once (may lose), at-least-once (may duplicate — the usual default), exactly-once (only within specific platform features).
Dead-letter queue
Where messages go after repeated failures, for inspection and replay.
Ordering
Kafka orders within a partition; RabbitMQ orders within a queue with one consumer.

Trade-offs

Benefits

  • Decouples producers from consumers in time and availability
  • Buffers traffic spikes
  • One event can feed many consumers

Costs

  • Eventual consistency and harder debugging
  • Duplicate and out-of-order messages must be handled
  • Another critical system to operate

Use it when

  • RabbitMQ: background jobs, work queues, complex routing
  • Kafka: event streams, audit logs, replays, high-volume pipelines
  • ActiveMQ: JMS-based enterprise integration

Common mistakes

  • Consumers that are not idempotent
  • Using Kafka as a simple job queue when RabbitMQ is simpler
  • No monitoring of queue depth or consumer lag
  • Publishing the event and saving to the database as two separate steps — use the outbox pattern

Interview questions

Q1How do you scale Kafka consumers?
Add consumers to the same group, up to the number of partitions. Each partition is read by one consumer in the group, so the partition count caps parallelism.
Q2What is the transactional outbox pattern?
Write the business change and the event to an outbox table in the same database transaction. A relay publishes outbox rows to the broker, so you never save without publishing or publish without saving.
Q3When would you choose RabbitMQ over Kafka?
For task distribution with per-message acknowledgement, routing rules, priorities and modest volume, where you don’t need to replay history.

Related lessons

Messaging & Microservices

Real-Time Event Streaming

Process continuous streams of events as they happen, not in nightly batches.

Advanced8 min read Messaging & Microservices

The Saga Pattern

Run a business transaction across services as a series of local steps with compensations.

Advanced9 min read APIs & Security

Idempotency & Preventing Double Payments

Make retries safe, so a timeout never charges a customer twice.

Advanced9 min read