When to pick RabbitMQ
Task queues between services: send — process — forget. Complex routing (by type, priority, with TTL and dead-letter), RPC patterns. No need for message history.
These are tools for different jobs, and the honest answer is often “you need RabbitMQ”. RabbitMQ is classic task queues with flexible routing. Roxa is event streaming: history is retained, can be replayed, and consumers are independent.
| Roxa | RabbitMQ | |
|---|---|---|
| Data model | Log/stream: history is kept and can be re-read | Queue: a message is delivered — and gone |
| Replaying history | Yes — any consumer from any offset | No (the streams mode is a separate story) |
| Multiple independent readers | Native: consumer groups with offsets | Via fanout plumbing |
| Routing | By key into a partition | Flexible: exchanges, routing keys, TTL, priorities |
| Storage | S3/MinIO or FS, retention by size/time | Node disk, mirrored by the cluster |
| Protocol | Kafka wire | AMQP 0-9-1 |
| Runtime | Rust, one container | Erlang/OTP |
Task queues between services: send — process — forget. Complex routing (by type, priority, with TTL and dead-letter), RPC patterns. No need for message history.
Events you cannot afford to lose and want to replay: orders, payments, audit, telemetry. Several independent consumers of one stream. A new service joins — and reads history from wherever it needs.
A special case: if your RabbitMQ is already used as “sort of streaming” with hand-rolled plumbing for re-reading — that is exactly the pain the log model was built for. Migration means switching the client (AMQP → Kafka), but Kafka clients exist for every language.