Do you know the difference between Kafka and RabbitMQ... or did you just put it on your resume?

Since last year, one of my responsibilities has been to interview those who apply for positions at the company they work for. What often happens is the following: many do not have resumes with tools like Kafka and RabbitMQ — which are present in most modern systems — but when I ask the classic question:

"What is the difference between these messaging services? And why did you use both?"

The answer almost always comes out as:

• "I don't know, I just used them."
• "They're all queues, right?"

💣 Spoiler: they're not.

If you really want to understand how these tools work and when to use each one, this article is for you. Let's talk about:

• The difference between a queue and a stream
• Why RabbitMQ is push-based and Kafka is pull-based
• When to use each approach

What is a queue? (RabbitMQ):

A queue is a FIFO (First In, First Out) data structure. When we talk about messages, the flow looks like this:

Producer ➡️ Queue ➡️ Consumer

Or, in more detail:

[1] The producer sends a message to the queue
[2] The broker delivers that message to a consumer
[3] The message is removed from the queue after consumption

If processing fails, the message can be resent — usually through a dead-letter queue.

Features:

• Guaranteed processing order (generally)
• Single consumer per message
• Transient storage

Examples of queue-based brokers:
RabbitMQ

• Amazon SQS
• Redis Streams (FIFO mode)

What is a stream? (Kafka)

A stream is an ordered, immutable record of events. Unlike a queue, messages are not discarded after consumption. Instead, the consumer reads the message from a given offset, and this log can be suspended for days or weeks (or indefinitely).

Typical flow:

Producer ➡️ Broker (log) ⬅️ Consumer

The consumer asks:

“Is there anything new for me after offset 128?”
And then he reads the message directly.

Features:

• Immutability: messages are not deleted immediately
• Configurable retention (e.g. 7 days by default in Kafka)
• Multiple consumers can read the same message independently

Examples beyond Kafka:

• Amazon Kinesis
• Apache Pulsar
• Redpanda

Push vs Pull: Who controls the pace?

• RabbitMQ(push)
  The broker pushes messages to consumers as soon as they are available.
  ✅ Lower latency
  ⚠️ Risk of overload if the consumer is not contagious

• Kafka (pull)
  The consumer pulls messages according to its own pace and offset.
  ✅ Easier reprocessing
  ⚠️ Require more control and logic on the consumer side

When to use each? RabbitMQ:

• Guaranteed and immediate delivery

• TTL or disposable message after consumption

• Not ideal for:

  • Reprocessing messages
  • Multiple consumers reading the same data

When to use each? RabbitMQ:

• Storing and reprocessing events
• Multiple concurrent consumers
• Processing large volumes with horizontal scalability

• Implementing event sourcing or stream processing

• Not ideal when:

  • Each message must be processed only once and summarized
  • You need advanced routing logic on the broker

Kafka ≠ Queue. This is the trick:
Kafka is not a queue.
Kafka is a distributed log with read control on the consumer.
RabbitMQ is a traditional message broker, based on delivery and removal.

🧠 Conclusion
Kafka and RabbitMQ solve different problems.
Using both is not wrong. Using them without understanding why is.
Kafka is about streaming, retention, performance and multiple consumers
RabbitMQ is about control, reliability and simplicity in routing
It is not enough to know how to use it.
Understand why.
📌 Messaging is an architecture, not a library.

💬 What about you?
Have you ever fallen into the trap of treating Kafka as a queue?
Have you ever had a project that used both... and didn't need either?
Tell us what you think, and share it with that friend who swears that Kafka is the best.