When to Choose Kafka Over RabbitMQ: A Six‑Scenario Comparison

Many developers wonder whether to use Kafka or RabbitMQ for a given requirement. The author examines this question by analyzing six typical scenarios and highlighting the strengths and weaknesses of each system.

1. Message Ordering

In an order‑status change workflow, strict ordering is required for each order. RabbitMQ creates a separate queue for each consumer and copies messages for broadcast, which can lead to out‑of‑order processing when a consumer thread fails and the message is re‑queued. Kafka stores messages in a log and allows consumers to read sequentially, preserving order and avoiding the re‑queue problem.

2. Message Routing (Matching)

RabbitMQ supports routing keys and custom headers via exchanges, making it easy to implement complex routing rules with little development effort. Kafka lacks built‑in routing; all consumers must read all messages and perform filtering or use external rule engines, increasing development complexity.

3. Message Timeout (Delayed Queues)

For order‑cancellation after a 15‑minute timeout, a delayed queue is needed. RabbitMQ provides a TTL field and dead‑letter queues, and with the rabbitmq_delayed_message_exchange plugin can handle per‑message delays. Kafka requires a temporary topic, a custom consumer to hold messages, persistence to a database, and later re‑publishing, which is cumbersome.

4. Message Persistence

Event sourcing scenarios need messages to be replayable. RabbitMQ deletes messages once consumed, making replay difficult. Kafka persists messages in a log that can be re‑read multiple times, supporting reliable replay.

5. Error Handling

Kafka stops consumption on a failed message within a partition, preventing further processing and requiring careful handling of “bad” messages. RabbitMQ can re‑queue failed messages or move them to a dead‑letter queue, allowing the rest of the stream to continue.

6. Throughput

Kafka can handle hundreds of thousands of messages per second, while RabbitMQ typically handles tens of thousands. However, most business applications do not need Kafka‑level throughput; RabbitMQ’s simpler configuration and lower operational overhead often make it a better fit.

Conclusion

Choosing a message queue should start by listing the most critical business characteristics and then comparing the detailed behavior of each system. In some cases, mixing both—using each where it excels—can maximize benefits and minimize costs.