Message Queues Explained: RabbitMQ vs Kafka vs SQS — When to Use What

Why Message Queues?

Imagine Service A needs to send emails after a user signs up. If it calls the email service directly:

• What if the email service is down? The signup fails.
• What if it's slow? The user waits.
• What if 10,000 users sign up at once? Everything crashes.

A message queue solves all three problems. Service A drops a message in the queue and moves on. The email service picks it up when it's ready.

Core Concepts

Producer → Queue → Consumer

The basic pattern is simple:

1. Producer publishes a message to the queue
2. Queue stores the message durably
3. Consumer pulls the message and processes it

The producer and consumer are completely decoupled — they don't know about each other.

Key Benefits

• Decoupling: Services evolve independently
• Buffering: Handle traffic spikes gracefully
• Reliability: Messages persist even if consumers are down
• Scalability: Add more consumers to process faster

The Big Three: RabbitMQ vs Kafka vs SQS

RabbitMQ

What it is: A traditional message broker implementing AMQP protocol.

Best for:

• Task distribution (send emails, process images)
• Complex routing (route messages based on headers/topics)
• Request-reply patterns
• When you need message-level acknowledgments

How it works:

• Messages are pushed to consumers
• Once acknowledged, messages are deleted
• Supports exchanges for flexible routing (direct, topic, fanout)

Apache Kafka

What it is: A distributed event streaming platform.

Best for:

• Event sourcing and event-driven architecture
• Real-time analytics and data pipelines
• Log aggregation
• When you need to replay events

How it works:

• Messages are appended to an immutable log (topic partitions)
• Consumers pull messages and track their own offset
• Messages are retained for a configurable period (not deleted after consumption)
• Partitions enable parallel processing

AWS SQS

What it is: A fully managed message queue service.

Best for:

• Simple async processing on AWS
• When you want zero operational overhead
• Decoupling Lambda functions and microservices

How it works:

• Standard queues: at-least-once delivery, best-effort ordering
• FIFO queues: exactly-once processing, strict ordering
• Fully serverless — no clusters to manage

Quick Comparison

Feature	RabbitMQ	Kafka	SQS
Delivery	Push	Pull	Pull
Ordering	Per-queue	Per-partition	Best-effort (FIFO available)
Retention	Until acknowledged	Time-based	4 days (configurable)
Throughput	Moderate	Very high	High
Replay	No	Yes	No
Operations	Self-managed	Self-managed	Fully managed

Common Patterns

1. Point-to-Point

One message → one consumer. Classic task queue.

2. Pub/Sub

One event → many subscribers. Each subscriber gets a copy.

3. Dead Letter Queue

Messages that fail processing N times go to a separate DLQ for investigation.

4. Competing Consumers

Multiple consumer instances read from the same queue — work gets distributed automatically.

When to Use What

• "I need to send background jobs" → RabbitMQ or SQS
• "I need to stream events to multiple consumers" → Kafka
• "I want zero ops and I'm on AWS" → SQS
• "I need to replay past events" → Kafka
• "I need complex message routing" → RabbitMQ

Learn More

Full guide at swehelper.com/blog/message-queues. Also check out the Kafka deep dive and Pub/Sub patterns.

Plus 119+ free developer tools at swehelper.com/tools — no signup required.