SQS vs RabbitMQ
Managed AWS queue vs self-hosted AMQP broker — pick by ops model, routing needs, and cloud footprint.
📌 Key IdeaSQS is a fully managed, pull-based queue ideal for AWS-native async workloads with minimal ops. RabbitMQ is a flexible AMQP broker with push delivery and rich routing, better when you need low-latency task dispatch, complex routing, or multi-cloud/on-prem deployment.
When to Use
- Choose SQS when you are on AWS, want zero broker ops, and need durable task buffering with DLQ support.
- Choose RabbitMQ when you need exchange-based routing, push delivery, priority/TTL queues, or run outside AWS.
- Use SQS + SNS when you need fan-out to multiple queues; use RabbitMQ fanout/topic exchanges for in-broker routing.
When NOT to Use
- Do not pick SQS when you need sub-100ms push latency or complex in-broker routing without SNS.
- Do not pick RabbitMQ when the team cannot operate HA clusters, patching, and capacity planning.
- Neither replaces Kafka/Kinesis when event replay and multi-subscriber log consumption are core requirements.
SQS vs RabbitMQ — Side-by-Side
| Aspect | SQS | RabbitMQ |
|---|---|---|
| System type | Fully managed AWS queue service | Self-hosted AMQP message broker |
| Deployment | Serverless — no cluster to run | You operate cluster (or use Amazon MQ / CloudAMQP) |
| Protocol / API | AWS SDK / HTTP API | AMQP 0.9.1 (+ MQTT, STOMP via plugins) |
| Delivery model | Pull — consumers poll the queue | Push — broker delivers to subscribed consumers |
| Routing | Single queue destination; fan-out via SNS → multiple SQS queues | Exchanges: direct, topic, fanout, headers — flexible routing in-broker |
| Ordering | Best-effort (Standard) or strict per message group (FIFO) | FIFO per queue (single active consumer per queue) |
| Delivery semantics | At-least-once (design idempotent handlers) | At-most-once or at-least-once via ack/nack + prefetch tuning |
| Throughput | Nearly unlimited (Standard); FIFO ~300 TPS default (3,000 with batching) | High with tuned prefetch, quorum queues, and horizontal consumers |
| Typical latency | Poll-based — long polling (up to 20s wait) adds seconds-scale latency | Push-based — lower end-to-end latency for ready consumers |
| Message retention | Up to 14 days | Until consumed (configurable TTL / queue limits) |
| Dead-letter handling | Native DLQ via maxReceiveCount + redrive | Native DLX/DLQ — mature poison-message patterns |
| Replay | No event log replay; redrive from DLQ only | No durable log replay — message removed after ack |
| Scaling | Automatic — AWS handles capacity | Manual — add nodes, tune prefetch, shard across queues/vhosts |
| Cost model | Pay per API request + data transfer | Infra cost (VMs/containers) + ops time for HA/monitoring |
| Portability | AWS-only — vendor lock-in | Runs on-prem, any cloud, Kubernetes |
| Observability | CloudWatch metrics + AWS-native alarms | Built-in management UI + Prometheus/Grafana plugins |
| Best fit | AWS microservices, Lambda/ECS workers, simple async decoupling | Complex routing, low-latency tasks, hybrid/multi-cloud, on-prem |
Key Trade-offs
| Area | SQS trade-off | RabbitMQ trade-off |
|---|---|---|
| Operations burden | ✅ Zero cluster ops, patching, or sizing | ❌ You own HA, upgrades, disk/memory tuning, and failover drills |
| Routing flexibility | ❌ Queue-only; complex routing needs SNS or app logic | ✅ Rich exchange topology without extra services |
| Latency profile | ❌ Pull + visibility timeout → higher baseline latency | ✅ Push delivery → faster dispatch to idle consumers |
| Vendor lock-in | ❌ AWS-specific API and pricing | ✅ Portable AMQP — same patterns across environments |
| Cost at low volume | ✅ Cheap when traffic is low (pay per use) | ❌ Fixed infra cost even when queues are idle |
| Cost at high volume | ❌ Per-request pricing can grow with poll frequency | ✅ Predictable cost once cluster is right-sized |
| Duplicate messages | ❌ At-least-once by default — duplicates on retry/timeout | ⚠️ Duplicates possible with at-least-once + nack/requeue — idempotency required either way |
| Ordering guarantees | ⚠️ FIFO only with throughput caps; Standard is best-effort | ✅ Natural FIFO per queue; scale by sharding into multiple queues |
| Developer experience | ✅ Simple send/receive API; integrates with Lambda natively | ✅ Mature client libraries; steeper learning curve for exchanges/bindings |
Common Confusions Cleared Up
Managed queue vs broker you operate
SQS removes broker operations entirely — no nodes, no quorum, no patch windows. RabbitMQ gives you full control and AMQP features but you (or a managed provider) must run and monitor the cluster.
Pull vs push changes backpressure behavior
SQS consumers control rate by polling frequency and batch size — natural backpressure but with latency cost. RabbitMQ pushes messages and relies on prefetch (basicQos) and consumer acks to prevent overload.
Both need idempotent consumers
Neither gives end-to-end exactly-once in real systems. Retries, visibility timeouts (SQS), and nack/requeue (RabbitMQ) can produce duplicates — idempotency keys and dedupe stores are mandatory for both.
Interview Q&A
Quick Cheat Sheet
Pick SQSAWS-only, zero ops, Lambda/ECS workers, simple buffering.
Pick RabbitMQComplex routing, push latency, on-prem/multi-cloud.
Both requireIdempotent handlers + DLQ for poison messages.
Neither isA replayable event log — use Kafka/Kinesis for that.
SQS latency tipLong polling (20s) + batch receive to cut empty polls.
RabbitMQ safety tipSet prefetch + DLX/DLQ + consumer ack after success.