At a Glance
| System | Core Model | Ordering Guarantee | Officially Documented Throughput |
|---|---|---|---|
| Apache Kafka | Distributed, partitioned commit log (log-based pub/sub) | Guaranteed only within a single topic-partition | No fixed numeric ceiling published; Kafka’s own docs emphasize that performance “stays roughly constant” as retained data grows |
| RabbitMQ | Traditional AMQP message broker (exchanges, bindings, queues) | FIFO within a single queue | ~80,000 msgs/sec on a replicated, fsync’d quorum queue; ~100,000 msgs/sec on a classic queue; multiple millions/sec via streams (all per RabbitMQ’s own published figures) |
| Amazon SQS | Fully managed cloud queue service (Standard or FIFO) | Standard: best-effort only. FIFO: strict order per message group | FIFO: 300 TPS/action unbatched, 3,000 msgs/sec batched; up to 70,000 TPS/action (region-dependent) with High Throughput Mode |
How Kafka Works: A Distributed Commit Log
Kafka’s own documentation describes events as being “organized and durably stored in topics,” which are multi-producer and multi-subscriber. Unlike a traditional queue, a message isn’t deleted once it’s read — Kafka retains events for as long as a configured retention period dictates, and performance stays roughly constant regardless of how much data has accumulated, since reads and writes are essentially sequential disk operations against an append-only log.
Each topic is split into partitions, which spread the topic across multiple brokers so clients can read and write in parallel. This is where Kafka’s ordering guarantee lives: events with the same key are routed to the same partition, and Kafka guarantees a consumer reading a given topic-partition receives events “in exactly the same order as they were written.” Crucially, that guarantee is per-partition, not per-topic — if you need strict ordering across an entire topic, you need exactly one partition, which caps your write parallelism. Brokers form the storage layer of a cluster, and topic-partitions are typically replicated (a replication factor of 3 is common in production), so that if one broker fails, another takes over without losing acknowledged data.
How RabbitMQ Works: Exchanges, Bindings, and Queues
RabbitMQ implements the AMQP messaging model (0-9-1 historically, with the RabbitMQ team now recommending AMQP 1.0 for new applications). Publishers don’t send messages directly to a queue — they send to an exchange, which routes the message according to its type and its bindings. RabbitMQ’s documentation defines four exchange types: direct (exact routing-key match), fanout (ignores the routing key, copies to every bound queue), topic (pattern-matches the routing key, for selective pub/sub), and headers (routes on header values rather than the routing key). Every queue is also automatically bound to a nameless default direct exchange using its own name as the routing key.
Queues themselves are strictly FIFO: ordered collections where messages are enqueued at the tail and dequeued from the head. RabbitMQ’s current documentation is explicit about a key architectural limit: “a single queue replica (whether leader or follower) is limited to a single CPU core on its hot code path,” which is why RabbitMQ recommends using multiple queues rather than one giant queue when you need to scale throughput — a single queue is called out as generally an anti-pattern at scale. For workloads that need to push past normal queue throughput, RabbitMQ offers streams: append-only, replicated logs with offsets and replay, conceptually closer to Kafka partitions than to a classic AMQP queue. Modern RabbitMQ also offers quorum queues (Raft-replicated, fsync’d per message before confirming) as the default durable queue type, trading some throughput for stronger delivery guarantees than classic queues.
How Amazon SQS Works: Fully Managed, Two Queue Types
SQS removes broker management entirely — AWS runs the service, and you interact with it only through the SendMessage, ReceiveMessage, and DeleteMessage API actions. Standard queues favor throughput over strict ordering: the AWS documentation says they support “a very high, nearly unlimited number of API calls per second, per action,” but ordering is best-effort and duplicate delivery is possible (at-least-once delivery).
FIFO queues trade some of that throughput for strict ordering within a message group and exactly-once processing. Per the AWS SQS Developer Guide, a standard (non-high-throughput) FIFO queue supports 300 transactions per second per API action without batching, or up to 3,000 messages per second per API action when batching up to 10 messages into a single call. For higher scale, AWS offers High Throughput Mode for FIFO queues, which raises per-API-action limits well beyond that — but the ceiling is region-dependent. In US East (N. Virginia), US West (Oregon), and Europe (Ireland), the documented limit is 70,000 TPS per action unbatched (700,000 messages/second batched); other regions step down from there, with a default of 2,400 TPS unbatched (24,000 batched) in regions not otherwise listed. These limits apply per API action and can be increased further via a Service Quotas request.
Throughput and Ordering Guarantees Compared
| System | Ordering Scope | Officially Published Throughput Figures |
|---|---|---|
| Apache Kafka | Within a single topic-partition only | No numeric throughput ceiling is published in Kafka’s own docs; capacity scales with partition count and broker hardware |
| RabbitMQ (quorum queue) | FIFO within the queue | ~80,000 messages/sec while replicating and fsyncing each message (RabbitMQ’s own comparison page) |
| RabbitMQ (classic queue) | FIFO within the queue | ~100,000 messages/sec |
| RabbitMQ (streams) | Offset-ordered within a stream | Several million messages/sec on a single well-batched stream; over 17 million messages/sec combined across five streams in RabbitMQ’s own benchmark |
| Amazon SQS FIFO (standard mode) | Strict order per message group | 300 TPS/action unbatched; 3,000 msgs/sec/action batched (10 msgs/batch) |
| Amazon SQS FIFO (High Throughput Mode) | Strict order per message group | Up to 70,000 TPS/action unbatched / 700,000 msgs/sec/action batched in top-tier regions; as low as 2,400 TPS/action (24,000 batched) by default elsewhere |
Trade-offs: Choosing the Right Tool
These three systems solve different problems well enough that “which is fastest” is often the wrong question. Kafka’s log-based model is built for durable, replayable event streams that multiple independent consumers read at their own pace — event sourcing, change-data-capture pipelines, and analytics ingestion are natural fits, and its own comparison documentation (published by RabbitMQ, which has every incentive to be fair here since it’s comparing itself) singles out tiered storage and log compaction as Kafka-only strengths. RabbitMQ’s exchange-and-binding model shines for task queues, RPC-style workloads, and routing logic that changes at runtime — its per-message features (TTL, 32 priority levels, delayed retry, dead-letter routing) suit workloads where individual messages matter, not just aggregate throughput. SQS trades flexibility for zero operational burden: there’s no cluster to patch, scale, or fail over, which is why it’s the default choice for decoupling services inside AWS, as long as your throughput needs fit inside its documented FIFO quotas (or you’re willing to shard across many message groups and queues to work around them).
Worth noting: RabbitMQ’s own documentation is candid that benchmark comparisons between Kafka and RabbitMQ streams land “in the same ballpark” for raw throughput and latency, and that one-sided tuning easily distorts any benchmark. Treat all vendor-published throughput numbers, including the ones in this article, as upper bounds achieved under specific, favorable configurations rather than guaranteed real-world results.
Bottom Line
Choose Kafka when you need a durable, replayable event log that many independent consumers read at different speeds. Choose RabbitMQ when you need flexible routing, per-message delivery guarantees, and priority/retry semantics for task-queue-style workloads, and you’re prepared to operate a broker (or use a managed one). Choose Amazon SQS when you’re already on AWS and want a queue with effectively no operational overhead, understanding that FIFO ordering comes with specific, documented throughput quotas you need to design around.
FAQ
Does Kafka guarantee global ordering across an entire topic?
No. Kafka only guarantees order within a single partition. A topic with multiple partitions has no guaranteed cross-partition order; if you need strict topic-wide ordering, use a single partition.
What’s the real throughput ceiling for RabbitMQ?
There’s no single number — it depends on queue type. RabbitMQ’s own documentation cites roughly 80,000 messages/second for a replicated, fsync’d quorum queue, about 100,000/second for a classic queue, and several million per second using streams, with the caveat that these figures depend heavily on configuration and batching.
Can an SQS FIFO queue scale past 300 TPS?
Yes, two ways: batch up to 10 messages per API call (up to 3,000 msgs/sec/action), or enable High Throughput Mode, which raises the per-action ceiling as high as 70,000 TPS unbatched in supported regions.
Which of the three requires the least operational overhead?
Amazon SQS, since AWS fully manages it end to end. Kafka and RabbitMQ both require you to operate a cluster yourself unless you use a managed offering (e.g. Confluent Cloud, Amazon MSK, or a managed RabbitMQ service).
Sources
- Apache Kafka Introduction — Apache Kafka Docs: https://kafka.apache.org/intro
- RabbitMQ vs. Apache Kafka — RabbitMQ Docs: https://www.rabbitmq.com/docs/compare/kafka
- Queues — RabbitMQ Docs: https://www.rabbitmq.com/docs/queues
- AMQP 0-9-1 Model Explained — RabbitMQ Docs: https://www.rabbitmq.com/tutorials/amqp-concepts
- Amazon SQS message quotas — AWS SQS Developer Guide: https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/quotas-messages.html
- Amazon SQS FIFO queue quotas — AWS SQS Developer Guide: https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/quotas-fifo.html
