Popular Messaging Queue Systems

Every asynchronous system eventually reaches for a message broker, but "RabbitMQ vs Kafka vs SQS vs ActiveMQ" is the wrong first question. The right first question is about mechanism: does your workload want a queue or a log? Almost every difference in throughput, ordering, replay, and operational cost falls out of that one choice. Learn the mechanism, and picking a product becomes a lookup instead of a guess.

The one distinction that explains everything: queue vs log

A queue (RabbitMQ, Amazon SQS, classic ActiveMQ) is a consume-and-destroy structure. The broker hands each message to one worker, waits for an acknowledgement, then deletes it. The broker owns delivery state; it actively pushes work and tracks who has what. Add more workers and they compete for messages off the same queue, which is exactly how you parallelise a task backlog. The message is gone once it is done — there is nothing to re-read.

A log (Apache Kafka) is an append-only, retained structure. Producers append records to the end of a partition; the broker keeps every record for a retention window (say 7 days) whether or not anyone has read it. Consumers are not handed messages — they pull and remember their own position with an offset, a bookmark into the log. Two independent consumer groups can read the same partition at different offsets without interfering, and either can rewind to re-process history. The broker is a dumb, fast file; the smarts live in the consumer.

That single mechanical difference — who owns the read position, and does the message survive being read — is the root cause of nearly every downstream trade-off:

• Replay: a log can replay history (reset the offset); a queue cannot (the message is deleted on ack).
• Fan-out: a log gives every consumer group its own full copy of the stream for free; a queue needs an explicit fan-out topology (exchanges, or SNS→SQS) because a delivered message is consumed.
• Ordering vs parallelism: a log preserves order within a partition but forces you to trade ordering for parallelism (one partition = one consumer per group); a competing-consumer queue parallelises trivially but loses global order.
• Throughput ceiling: a log's sequential disk append and zero-copy reads push millions of msg/s per broker; per-message-ack queues do far less because tracking and deleting each message is expensive.

A workload-signal rubric: read your requirements, not the marketing

Skip feature checklists. Instead, match the signal in your workload to the mechanism, then to a product:

Two signals dominate in practice: "is the message a task or an event?" (task → queue; event others may also care about → log) and "do I ever need to look at it twice?" (yes → log). Get those two right and the rest is tuning.

The major systems — with when-to-use, when-NOT, and the trade-off vs the named alternative

RabbitMQ — the smart queue / router

A mature AMQP broker whose exchanges (direct, topic, fanout, headers) do routing inside the broker. Push-based delivery with per-message acks, dead-letter queues, TTLs, and priority queues.

• Use when: you need flexible routing and per-message workflow control — RPC-style request/reply, priority jobs, complex topologies where a message's type decides its destination.
• Do NOT use when: you need to replay history or fan the same stream out to many independent readers at high volume. Once a message is acked it is gone, and very deep queues (millions of unacked messages) degrade the broker because it tracks per-message state in memory.
• Trade-off vs Kafka: RabbitMQ gives you richer routing and lower per-message latency for task dispatch, but Kafka wins on raw throughput, retention, and replay. Choose RabbitMQ when the broker's routing logic is the value; choose Kafka when the durable, replayable stream is the value.

Apache Kafka — the distributed log

Partitioned, replicated, append-only commit log. Producers key records to partitions; consumers in a group split partitions among themselves and commit offsets. Retention is time/size-based, independent of consumption.

• Use when: event streaming, log/metric aggregation, event sourcing, CDC, or any pipeline where multiple downstream systems consume the same feed and you may need to replay.
• Do NOT use when: you need per-message priorities, selective/random-access acknowledgement, or delayed/scheduled delivery of individual messages — the log has no concept of "skip this one, deliver that one later." It's also heavy operationally for a simple background-job queue.
• Trade-off vs RabbitMQ/SQS: you gain throughput, retention, and free fan-out, but you inherit partition-count capacity planning and the rule that per-group parallelism is capped at the partition count. Ordering only holds within a partition, so you must key carefully.

Amazon SQS — the managed queue you never operate

Fully managed, effectively infinite-scale queue. Standard queues are at-least-once with best-effort ordering; FIFO queues add strict per–message-group ordering and a content-based deduplication window (not free exactly-once side effects — make consumers idempotent). No brokers to run; pay per request.

• Use when: you're on AWS, want zero operational burden, and need a durable buffer between services (decoupling, load-levelling, retry with visibility timeout + DLQ).
• Do NOT use when: you need fan-out to many consumers (pair it with SNS for that), replay of consumed messages, message priorities, or ordering across the whole queue rather than within a group.
• Trade-off vs Kafka: SQS erases operational cost and scales without capacity planning, but it deletes on delete-call (no replay) and offers no native multi-subscriber streaming — SNS→SQS fan-out is a workaround, not a log.

Apache ActiveMQ — the JMS workhorse

A multi-protocol broker (JMS, AMQP, STOMP, MQTT, OpenWire) strong in Java/enterprise-integration settings. Classic ActiveMQ is queue-oriented; ActiveMQ Artemis is the modern high-performance engine.

• Use when: you live in a JMS/Java-EE/Spring world, need multiple wire protocols through one broker, or are integrating legacy enterprise systems.
• Do NOT use when: you need Kafka-scale streaming and replay, or you'd rather not run a broker at all (choose SQS).
• Trade-off vs RabbitMQ: broadly overlapping capabilities; ActiveMQ leads on JMS/enterprise-Java integration and protocol breadth, RabbitMQ tends to have the larger community and simpler operational story for non-JMS stacks.

NATS — the lightweight cloud-native broker

NATS is a fast, simple messaging layer built for cloud-native workloads where operational overhead is the enemy. The core server is a single binary; it speaks publish-subscribe and request-reply out of the box and can route messages across a cluster with no leader election ceremony.

• Use when: you need low-latency fan-out or service discovery between microservices, want a tiny operational footprint, or need multi-region message routing without the heft of a distributed log.
• Do NOT use when: you need long-term retention or replay by default — core NATS is at-most-once fire-and-forget. For durability and replay, NATS JetStream adds persistence, streams, and consumer offsets, but it is a separate operational mode with different guarantees.
• Trade-off vs Kafka: NATS wins on simplicity, latency, and ease of operation; Kafka wins on throughput, retention, and the maturity of its ecosystem (Connect, Streams, exactly-once transactions). Choose NATS for control-plane and service-mesh-style traffic; choose Kafka for durable event sourcing and analytics pipelines.

Apache Pulsar — the tiered-storage log

Pulsar separates compute (brokers) from storage (Apache BookKeeper), which lets you scale message ingestion independently from storage. It supports both streaming (durable, rewindable) and queuing (ack-and-delete) models in one system, and it can offload old segments to object storage like S3 for effectively infinite retention.

• Use when: you need Kafka-like streaming with longer retention than local disks allow, multi-tenancy with strong isolation, or the ability to serve both queue and stream workloads from one cluster.
• Do NOT use when: you want the simplest possible operational model. Pulsar's architecture is more powerful but also more moving parts (brokers, BookKeeper, ZooKeeper/etcd) than a single Kafka cluster or a managed queue.
• Trade-off vs Kafka: Pulsar offers tiered storage, unified queuing/streaming, and cleaner multi-tenancy; Kafka offers a larger ecosystem, simpler single-cluster operation, and more tooling. For most teams the decision is ecosystem and operational familiarity more than raw capability.

Traced example: two workloads through the same lens

Watch how the mechanism forces the choice with concrete numbers.

Workload 1 — Order-confirmation emails (a task)

An e-commerce checkout emits 2,000 orders/min ≈ 33 msg/s. Each message triggers exactly one email. Emails must not be sent twice, but never need re-reading, and no other team consumes them.

• Signal: task, done once, single consumer, no replay → queue.
• Sizing: an email send takes ~200 ms, so one worker clears ~5 msg/s. To hold 33 msg/s with headroom: ~10 competing workers off one queue. Traffic spike to 20,000 orders/min (333 msg/s)? Scale to ~70 workers — the queue's competing-consumer model absorbs it with no re-partitioning.
• Pick: SQS (on AWS, zero ops) or RabbitMQ (if you want priority/retry routing). Visibility timeout + DLQ handles a crashed worker: an unacked message reappears after the timeout and is retried, then dead-lettered after N attempts.
• Why not Kafka? With one logical consumer and no replay need, Kafka's retention and partitioning are pure overhead — and to reach 70 parallel workers you'd need ≥70 partitions provisioned up front.

Workload 2 — Clickstream events (an event)

A site emits 500,000 clicks/min ≈ 8,300 msg/s. Three independent teams want them: real-time analytics, the search-ranking model, and a fraud audit trail. Analytics occasionally needs to reprocess the last 3 days after a bug fix.

• Signals: high throughput + multiple independent consumers of the same stream + replay → log, decisively.
• Sizing: at 8,300 msg/s a single Kafka broker is nowhere near stressed, but partition count sets consumer parallelism. If analytics processes ~1,000 msg/s per instance, you need ≥9 partitions to run 9 analytics consumers in parallel; provision 12 partitions for headroom. Key by user_id so each user's clicks stay ordered within a partition.
• Fan-out is free: analytics, search, and audit each run as their own consumer group with independent offsets — three full copies of the stream, no extra topology. Replay = reset the analytics group's offset to 3 days ago; the events are still on disk because retention is 7 days.
• Pick: Kafka. SQS would force an SNS fan-out to three queues and still couldn't replay consumed messages; RabbitMQ would strain on retained volume and lose the offset-rewind capability.

Same rubric, opposite answers — because one workload is a task and the other is a retained, multi-reader event stream.

Production failure modes worth knowing before you commit

• Kafka — the hot partition. Ordering lives inside a partition, so if you key by something skewed (e.g. one whale tenant_id), that partition's single consumer becomes the bottleneck while others idle. Symptom: rising lag on one partition only. Fix: choose a higher-cardinality key or add a salt, accepting weaker per-entity ordering.
• Kafka — consumer-group rebalance storms. A slow consumer that misses max.poll.interval.ms is evicted, triggering a rebalance that pauses the whole group; if the root cause persists you get repeated rebalances and stalled throughput. Fix: shrink batch size / raise the interval, and prefer cooperative-sticky assignment.
• RabbitMQ — unbounded queue growth. Because delivery state is tracked per message, a consumer outage lets a queue balloon into millions of messages, pushing the broker into memory/flow-control alarms that throttle publishers. Fix: set queue length limits, TTLs, and lazy queues; alert on depth.
• RabbitMQ — poison-message ack loops. A message that always crashes the consumer is redelivered forever unless you dead-letter it. Fix: DLX with a redelivery cap.
• SQS — visibility-timeout duplicates. If processing outlasts the visibility timeout, SQS assumes the worker died and redelivers, so a slow job runs twice. Because Standard SQS is at-least-once, consumers must be idempotent regardless. Fix: set the timeout above your P99 processing time (or extend it heartbeat-style) and dedupe on a business key.
• SQS FIFO — the throughput ceiling. A default FIFO queue is capped at 300 messages/second per queue (or 3,000/s per queue with batching of 10 messages per API call) — this limit is per queue / per API action, not per message group, so you cannot raise total throughput on a default queue simply by spreading load across more message groups. Per-message-group (partition) scaling only applies when you explicitly enable high-throughput FIFO mode, which lifts these limits substantially. Fix: if you need more than a few hundred msg/s on FIFO, enable high-throughput FIFO from the start, or reconsider whether Standard SQS (with idempotent consumers) or a keyed Kafka partition fits better.

Notice the through-line: the queue systems fail on per-message state and redelivery; the log fails on partitioning and rebalance. That's the mechanism reasserting itself — and it's why picking on mechanism first, product second, is the durable skill.

Sources

• Apache Kafka Documentation — Design, Replication, and the Consumer Group Protocol. kafka.apache.org/documentation.
• RabbitMQ Documentation — Queues, Consumer Acknowledgements, Dead Letter Exchanges, and Flow Control / Memory Alarms. rabbitmq.com/docs.
• Amazon SQS Developer Guide — Standard vs FIFO queues, Visibility Timeout, and "High throughput for FIFO queues" (the 300 / 3,000 TPS per-queue quotas and the high-throughput mode that scales per message group / partition). docs.aws.amazon.com/AWSSimpleQueueService.
• Apache ActiveMQ / Artemis Documentation — Protocols and JMS support. activemq.apache.org.
• Jay Kreps, "The Log: What every software engineer should know about real-time data's unifying abstraction" (LinkedIn Engineering) — the log-vs-queue mental model.

Queue vs log vs pub/sub decision flowchart

Delivery honesty: classic queues (RabbitMQ, ActiveMQ, SQS) are at-least-once by default. None of them give “exactly-once processing out of the box.” Effectively-once is usually at-least-once delivery + idempotent consumers (and, where offered, broker-side dedup windows such as SQS FIFO’s content-based deduplication — still not a free lunch for side effects).

Need durable replay / high fan-out / long retention?
    YES  -> log broker (Kafka / Pulsar)
    NO   -> need durable task dispatch + flexible routing / per-message acks?
              YES -> classic message queue (RabbitMQ / ActiveMQ)  // at-least-once; make consumers idempotent
              NO  -> need sub-millisecond pub/sub simplicity?
                       YES -> NATS (add JetStream only if you need persistence)
                       NO  -> managed queue (SQS / Azure Service Bus)  // also at-least-once by default

Drill ladder: queue vs log

• L1 — Queue vs log: who owns the read position?
  Trap: "the broker always tracks what each consumer has read."
  Bar: In a log, the consumer owns its offset — the broker is a dumb retained file, which is exactly why N groups and replay are free. In a queue, the broker owns delivery state per message and deletes on ack — which is exactly why redelivery, priorities, and per-message retry are natural there and replay is impossible.
• L2 — Why can't RabbitMQ replay history?
  Trap: "just turn on persistence."
  Bar: Persistence is not retention. A persistent RabbitMQ message survives a broker restart until it is acked — then it is deleted by design, because the broker's data structure is per-message delivery state, not a retained sequence. Replay needs the retained-log structure (Kafka, or RabbitMQ Streams — which is a different primitive bolted onto the same broker, not a flag on a queue).
• L3 — What causes a Kafka consumer-group rebalance storm, and why does adding consumers make it worse?
  Trap: "the group is slow — add more consumers."
  Bar: A member that exceeds max.poll.interval.ms is evicted → rebalance → the group pauses → the survivors inherit more partitions and are now slower → evicted again: the storm feeds itself. Each added consumer is another join event and another chance to flap; the fix is to shrink per-poll work or raise the interval (and prefer cooperative-sticky assignment / static membership), not to pour members into an unstable group.
• L4 — You chose SQS FIFO and now need 5,000 msg/s. Walk the quota math.
  Trap: "spread the load across more message groups."
  Bar: A default FIFO queue caps at 300 msg/s per queue, or 3,000/s with 10-message batching — and the limit is per queue / per API action, not per message group, so more groups change nothing. 5,000 msg/s > 3,000/s means a default queue cannot do it even fully batched. Two escapes: enable high-throughput FIFO mode, which scales the quota per message group; or drop to Standard SQS + idempotent, dedup-keyed consumers if per-group ordering was negotiable all along.