# SQS vs SNS

> Use SQS to buffer work for consumers that pull and process messages at their own pace. Use SNS to publish an event to multiple independent subscribers. When each subscriber needs durable buffering and independent retries, put a separate SQS queue behind each SNS subscription.

Source: https://sysround.com/compare/sqs-vs-sns
Updated: 2026-11-05


## Side by side

| | SQS | SNS |
|---|---|---|
| Core model | SQS: durable work queue | SNS: publish/subscribe topic |
| Who receives a message | Competing workers share a queue's work | Each matching subscription gets a copy |
| Delivery mechanism | Consumers pull, usually with long polling | Service delivers to subscribed endpoints |
| Slow consumers | Messages accumulate within retention limits | Endpoint-specific retries; use SQS for buffering |
| Processing success | Consumer deletes after processing | Endpoint acceptance, not necessarily business completion |
| Ordering and duplicates | Standard: best effort ordering, possible duplicates; FIFO available | Standard: best effort ordering, possible duplicates; FIFO available |
| Failure handling | Visibility timeout, redelivery, queue DLQ | Delivery retries and subscription DLQ |
| Typical interview role | Worker pool, burst buffer, background jobs | Event fan-out, subscriber decoupling, filtering |

## The differences that matter

A single SQS queue distributes work among competing consumers. It does not give every worker or service an independent copy. SNS fans an event out to matching subscriptions, so billing, email, and analytics can each receive the same event. For independent durable processing, give those services separate SQS queues subscribed to the topic.

SQS separates message arrival from processing capacity. Workers pull when ready, and unprocessed messages remain available within the configured retention period, up to 14 days. SNS delivers to endpoints and retries failures according to the endpoint's delivery policy. Direct SNS delivery is not a substitute for a consumer-controlled work backlog.

SQS processing uses a visibility timeout: receiving a message temporarily hides it, and the worker deletes it after success. If the worker crashes or runs past that timeout, the message can be delivered again. SNS considers delivery successful when the destination accepts it under that protocol, which may happen before downstream business work finishes.

Standard queues and topics can deliver duplicates and do not guarantee strict ordering. FIFO variants support ordering within message groups and deduplication under defined conditions; SNS FIFO fan-out uses SQS subscriptions. Neither option makes a database update or external API call exactly once, so consumers still need idempotent side effects.

Failure isolation depends on where you put the queue. In SNS-to-SQS fan-out, a subscription DLQ captures failures to deliver into the queue, while the queue's processing DLQ captures messages workers repeatedly fail to handle. Monitor both boundaries rather than treating all failures as the same retry problem.

## Choose SQS when

- A background task should be processed by one worker pool, such as image resizing or report generation.
- Traffic arrives in bursts, and workers need a durable backlog they can drain at a controlled rate.
- Workers must acknowledge completion explicitly and retry work after crashes or timeouts.
- You need queue-level controls for retention, visibility timeouts, delayed delivery, and poison-message handling.

## Choose SNS when

- One business event needs to reach several independent services rather than just one worker pool.
- The publisher should not maintain a list of downstream service endpoints.
- Different subscribers need different subsets of events, selected through subscription filters.
- You need delivery to supported endpoint types such as HTTPS, Lambda, or SQS, with endpoint-specific failure handling.
- You want SNS-to-SQS fan-out so each service gets its own durable queue, backlog, and processing policy.

## Worked example: Isolating an email outage from order processing

Assume an order service publishes 1,000 events per second, and both email and analytics need every event. Publish to SNS with separate SQS subscriptions for email and analytics. If email workers stop for 10 minutes, the email queue accumulates about 600,000 messages while analytics continues normally. After recovery, email workers processing 2,000 messages per second drain that backlog in about 10 minutes, assuming arrivals stay at 1,000 per second. A single shared queue would distribute events between the services rather than copy them to both. Configure retention, processing DLQs, queue-age alarms, and idempotent email handling.

## In the interview

- Start with the delivery requirement: does one worker need to perform a task, or does every interested service need its own copy? This is more useful than comparing product feature lists.
- Draw SNS feeding separate SQS queues when multiple services need independent progress. Explain that multiple services reading one queue would compete for messages instead of each receiving every event.
- Define the success boundary: publication accepted, message delivered to a queue, or business processing completed. Expect questions about a worker crashing after a side effect but before deleting the message.
- Estimate arrival rate, processing capacity, outage backlog, and drain time. Explain how queue age, worker scaling, downstream rate limits, and retention constrain recovery.
- State ordering scope and duplicate handling explicitly. If choosing FIFO, justify the message-group key and discuss how a hot group or failed message can delay subsequent work.

## Common mistakes

- Calling SQS and SNS interchangeable messaging services without distinguishing work distribution from fan-out.
- Putting email, billing, and analytics consumers on one SQS queue and expecting each service to receive every event.
- Treating SNS delivery success as proof that business processing finished, or treating FIFO deduplication as exactly-once side effects.
- Assuming retries provide unlimited durability while ignoring retention, exhausted delivery attempts, DLQs, and recovery procedures.

## Interview questions where it comes up

- [Design a notification system](https://sysround.com/questions/design-notification-system): SNS-to-SQS fan-out provides independent channel queues with separate worker capacity, retries, and failure isolation.
- [Design a distributed message queue like RabbitMQ](https://sysround.com/questions/design-message-queue): SQS illustrates visibility leases, explicit deletion, duplicate delivery, and poison-message handling.
- [Design a video streaming service like YouTube](https://sysround.com/questions/design-youtube): Upload events can fan out to independent processing queues, while transcoding jobs use queues to distribute work among workers.
- [Design a food delivery app like DoorDash](https://sysround.com/questions/design-doordash): Order lifecycle events may need separate durable consumers for notifications, restaurant workflows, and delivery coordination.
- [Design Google Photos](https://sysround.com/questions/design-google-photos): A completed upload can trigger independent image-processing and indexing pipelines without coupling their processing rates.

## FAQ

### What is the main difference between SQS and SNS?

SQS is a queue that consumers pull from to process shared work. SNS is a publish/subscribe service that delivers an event to matching subscriptions. Choose based on whether you need one worker pool to handle a task or multiple subscribers to receive copies.

### Why use SNS and SQS together?

SNS provides fan-out, while a separate SQS queue gives each subscriber durable buffering and control over processing speed. This lets one service fall behind without blocking the others. Each queue can have its own workers, retention settings, and processing DLQ.

### Do SQS and SNS guarantee message ordering or exactly-once processing?

Standard SQS queues and SNS topics do not guarantee strict ordering and can deliver duplicates. FIFO variants provide ordering within message groups and deduplication subject to their documented conditions. They do not make external side effects exactly once, so use idempotency keys or transactional deduplication where correctness requires it.

## Related concepts

- [Message queues](https://sysround.com/concepts/message-queues)
- [Publish-subscribe](https://sysround.com/concepts/pub-sub)
- [Fan-out on write and on read](https://sysround.com/concepts/fan-out)
- [Idempotency and idempotency keys](https://sysround.com/concepts/idempotency)
- [Dead-letter queues](https://sysround.com/concepts/dead-letter-queue)


---
SysRound (https://sysround.com) is an AI practice tool for system design interviews: a voice or typed AI interviewer, a shared whiteboard, then feedback on every skill and a model answer. Its feedback is AI-generated and can be wrong.