Kafka vs RabbitMQ vs SQS
The major differences between the three messaging systems, side by side
All three move messages between services, but they are built around different models. Kafka is a durable, replayable event log for streaming; RabbitMQ is a smart broker with rich routing for task queues and RPC; SQS is a fully-managed cloud queue on AWS that trades features for zero operations. The table below contrasts them on the dimensions that usually decide the choice.
| Dimension | Apache Kafka | RabbitMQ | Amazon SQS |
|---|---|---|---|
| Core model | Distributed, partitioned commit log (event stream) | Smart broker on AMQP 0-9-1 (exchanges + queues) | Fully-managed cloud queue (no broker to run) |
| Consumption | Pull; consumer groups track offsets | Push; broker delivers to consumers | Pull; poll with visibility timeout |
| Message retention | Kept by time/size; not deleted on read | Deleted once acknowledged | Deleted on delete; max 14 days retention |
| Replay history | Yes — re-read from any offset | No — consumed messages are gone | No — consumed messages are gone |
| Ordering | Strict per partition (by key) | Per queue; lost across competing consumers | None (Standard) / per group (FIFO) |
| Delivery guarantee | At-least-once; exactly-once within Kafka | At-least-once (at-most with auto-ack) | At-least-once (Standard) / exactly-once (FIFO) |
| Routing | Topic + partition key; no complex routing | Rich — direct, topic, fanout, headers | None natively; use SNS for fan-out |
| Throughput | Very high (millions/sec) | Moderate (tens of thousands/sec) | High / near-unlimited (Standard) |
| Latency | Low (single-digit ms) | Very low (great for RPC) | Higher (polling, tens of ms) |
| Max message size | ~1 MB default (configurable) | Large (configurable; big msgs discouraged) | 256 KB (use S3 claim-check for more) |
| Priority messages | No | Yes (priority queues) | No |
| TTL / delay | Retention-based only | Per-message & per-queue TTL | Delay up to 15 min; retention up to 14 days |
| Dead-lettering | Manual (no native DLQ) | Native dead-letter exchange (DLX) | Native dead-letter queue (DLQ) |
| Scaling unit | Partitions (+ brokers) | Queues + consumers | Automatic, fully managed |
| Operations | Complex self-host (or MSK / Confluent) | Self-host cluster (or CloudAMQP) | Zero ops — AWS managed |
| Protocol | Custom binary over TCP | AMQP 0-9-1 (+ MQTT, STOMP) | HTTPS REST API (AWS SDK) |
| Best fit | Event streaming, analytics, replay, sourcing | Complex routing, task queues, RPC | Simple decoupling & serverless on AWS |
Which one should you reach for?
Kafka
Durable event stream
- Many consumers read the same stream independently
- You need to replay historical events
- Very high throughput pipelines (logs, metrics, IoT)
- Stream processing and event sourcing
RabbitMQ
Smart routing broker
- Complex routing (topic / headers / fanout)
- Per-message priority, TTL, or RPC request-reply
- Classic task/work queues at moderate scale
- You want delivery features without huge volume
Amazon SQS
Managed cloud queue
- You are on AWS and want zero operations
- Decoupling and buffering between services
- Distributing tasks to workers or Lambda
- Simple fan-out when paired with SNS
One-line rule of thumb
Pick Kafka for high-volume event streams that many consumers read and replay; RabbitMQ when routing, priorities, or RPC matter at moderate scale; SQS when you are on AWS and want a simple, hands-off queue.