BullMQ vs RabbitMQ vs Kafka: how to actually choose

The question is usually asked too early. A team notices requests timing out behind a slow third-party API, someone says "we need a queue", and the next two weeks go into evaluating brokers. The evaluation is the wrong first step, because all three options solve the immediate problem and the differences only start to matter later.

Here is the short version. BullMQ is a job queue for Node.js backed by Redis. RabbitMQ is a general-purpose message broker with rich routing. Apache Kafka is a distributed, durable event log. They are three different categories of tool that happen to overlap on one use case.

The comparison that matters

The row people skip is the fourth. In BullMQ and RabbitMQ a message is consumed and gone. In Kafka it stays in the log, so a new consumer can read history from the beginning. If you ever need to replay six months of events into a new service, that is a Kafka property and you cannot retrofit it.

When BullMQ is the right answer

If you are a Node.js team, you already run Redis, and the problem is "slow work is blocking requests", BullMQ is almost always correct. It gives you retries with backoff, delayed and repeatable jobs, priorities, rate limiting and concurrency control, and you can be running in an afternoon.

This is what we reached for on an ecommerce SaaS whose MVP was stalling under concurrent load, described in scaling a SaaS with event-driven architecture. Orchestrators enqueue jobs, separate worker pools consume them, and one degraded marketplace API stops being able to take down billing.

The honest limitation: BullMQ's durability is Redis's durability. Redis persistence is good but it is not a replicated commit log, and if losing a job would mean losing money you owe someone, size that risk deliberately rather than assuming.

When RabbitMQ earns its keep

RabbitMQ becomes the right answer when routing gets interesting and the producers and consumers are not all the same language. Topic exchanges, fanout, per-queue policies and dead-letter exchanges are first-class, and clients exist for every runtime.

If you have a Python service that needs to react to events emitted by a Node service and a Go service, RabbitMQ is a more natural fit than bolting all three onto a Redis-backed job queue designed for one ecosystem.

When Kafka is worth the weight

Kafka is a genuinely different tool and carries real operational cost. It earns that when you need durable, replayable, high-throughput streams — event sourcing, analytics pipelines, multiple independent consumers of the same stream, or an audit log that must survive.

The failure mode is choosing Kafka for a workload that is really background jobs. You get a system your team cannot debug at 3am, in exchange for guarantees you were not using. If your throughput is in the hundreds of messages per second and nothing needs replaying, Kafka is a liability rather than an upgrade.

The part that matters more than the choice

Whichever you pick, moving work out of the request introduces the same two problems, and getting them wrong hurts more than picking the "wrong" broker.

Every job must be idempotent

Jobs will run more than once. A worker dies mid-task, a pod is rescheduled, an upstream times out after having actually succeeded. All three systems give you at-least-once delivery in practice, so a retry must be safe. Key each job by something stable, record completion, and check before acting.

Scale on queue depth, not CPU

Workers waiting on a slow API use almost no CPU, so CPU-based autoscaling never triggers while the backlog grows. Scale on queue depth instead: KEDA exposes queue length as a metric to the Kubernetes horizontal pod autoscaler, which turns a backlog into a cost line rather than an incident.

The decision, compressed

1. Node.js codebase, Redis already running, background jobs — BullMQ. Revisit only if that stops being true.
2. Several languages, or routing rules more complex than "this queue, these workers" — RabbitMQ.
3. Replay, event sourcing, or many independent consumers of one high-volume stream — Kafka.
4. Not sure — start with the lightest option that solves today's problem. Swapping a queue later is a week of work. Running Kafka you did not need is a permanent tax.

If the real problem is that your product is buckling under load rather than which broker to adopt, why MVPs break at scale covers the pattern, and scale and re-architecture is the work we do about it.

Frequently asked questions

References

1. BullMQ documentation — BullMQ
2. RabbitMQ — Broadcom
3. Apache Kafka — Apache Software Foundation
4. Horizontal Pod Autoscaling — Kubernetes Docs
5. KEDA: Kubernetes Event-driven Autoscaling — KEDA