RabbitMQ is a postman, Kafka is a ledger

When I teach RabbitMQ, I start with a postman. The producer is the sender, the message a letter, the exchange a sorting centre, the routing key the address, the queue a letterbox. The binding is the road from the sorting centre to the box: no binding, and the letter is not routed.

The analogy holds one more truth: once the letter is delivered, the postman forgets it. When a consumer acknowledges a message, RabbitMQ records it as delivered and can discard it. The queue is a waiting room, not an archive. Since 2021 RabbitMQ has also offered streams, a log of its own, but its classic and quorum queues, the ones most teams use, still work this way.

Kafka is a ledger. A producer appends events to a topic, and they stay there, read or not, for as long as the topic’s retention allows. Each consumer group keeps its own position in the log. A new consumer can start from the beginning; once its bug is fixed, a consumer can go back and read again.

The question is not which one is faster. It is what you need once the message has been delivered

If the answer is nothing, because the work is done once the order is processed or the notification sent, a postman fits. Its routing is rich, its model simple, and a message that matters is protected by durable queues, persistent messages, manual acknowledgements and a dead letter queue.

If the answer is a history — another team reading the same events next year, a service rebuilt from what happened, an audit — you need a ledger. And a ledger demands a discipline a postman does not: retention to size, partitions to plan, idempotent consumers, because reading again is now a feature.

The worst choice is the reflex. In an architecture assessment I once wrote one line for the teams: Kafka is not a JMS. Using a ledger as a postman, or asking a postman to keep the archive, is how a sound product ends up blamed for a bad decision.

Choose by what happens after delivery