How it works
Producers send messages to a regional queue through the SQS API. SQS stores messages redundantly across multiple Availability Zones and manages the underlying infrastructure. You choose queue type and settings, not broker nodes, storage replicas, or partition placement.
Consumers pull messages with ReceiveMessage, preferably using long polling to reduce empty responses. Receiving a message does not remove it. Instead, a visibility timeout temporarily hides it from other receives, and the consumer gets a receipt handle used to change visibility or delete that delivery.
After completing the work, the consumer calls DeleteMessage. If the worker crashes or cannot delete the message before visibility expires, the message can become available again. This creates a failure window between committing a business effect and deleting the message, so the application needs idempotent effects or transactional deduplication.
Standard queues provide at-least-once delivery and best-effort ordering. FIFO queues order messages within each MessageGroupId and suppress duplicate sends within a five-minute deduplication window. FIFO does not make external side effects exactly once: a worker can still repeat work after a failure.
Queue settings control retention, delivery delay, visibility, and redrive to a dead-letter queue. SQS is a work queue rather than a replayable event log: consumers normally delete completed messages, and independent subscribers need separate queues, often populated through Amazon SNS or EventBridge.
What it gives you in a design
- Durable asynchronous work distribution
- Multiple workers can pull from one queue to share work. Separating producers from consumers lets a request finish before expensive processing and lets temporary consumer outages accumulate a backlog rather than immediately fail producers.
- Visibility leases
- The visibility timeout gives a worker time to process a received message without normal competing delivery. Workers can extend visibility for long-running tasks, but visibility is not a distributed lock or an exactly-once guarantee.
- FIFO message groups
- Use MessageGroupId to serialize work for an entity, such as an order or account, while processing different groups concurrently. A slow message blocks later messages in its group, so choosing the group key is a throughput and correctness decision.
- Retries and dead-letter queues
- Failed work can become visible again, and a redrive policy moves repeatedly received messages to a dead-letter queue. Set maxReceiveCount to tolerate transient failures, then investigate and safely redrive failures rather than retrying poison messages forever.
- Long polling and batch APIs
- Long polling waits for messages instead of repeatedly returning empty responses. Batch send, receive, and delete operations reduce API overhead, but batch write responses can contain individual failures that must be handled separately.
- Delayed delivery
- Queue delays postpone initial message availability, and Standard queues also support per-message timers. Delays are bounded, so use a scheduler for deadlines far into the future rather than treating SQS as a general-purpose calendar.
- Access controls and encryption
- IAM and queue policies control who can send, receive, and manage messages. Server-side encryption and private access through VPC endpoints can support security requirements, but application logs, payload contents, and downstream permissions still need separate controls.
Scaling, replication and failure
Standard queues scale through AWS-managed infrastructure; applications do not assign messages to explicit partitions. Scale consumers using backlog per worker, message age, and measured processing time, while respecting downstream database and provider capacity. A queue absorbs a burst but does not eliminate the work or its cost.
FIFO concurrency depends on the number of active message groups and the applicable throughput settings and quotas. One hot group remains serial even if many workers are available. Choose the narrowest ordering scope the business requires, and preserve sequential processing within a group even when a receive returns multiple messages from that group.
SQS replicates message storage across Availability Zones within a Region. It does not automatically provide a cross-Region replicated queue; regional recovery requires an explicit producer, routing, and recovery strategy. Queue-depth metrics are approximate, so use them for control and monitoring rather than transactional correctness.
When processing slows, messages remain in flight longer, retries can increase, and message age grows. Bound worker concurrency, extend visibility when appropriate, and alert on oldest-message age and dead-letter arrivals. Ensure retention exceeds the outage and backlog-draining time you intend to tolerate.
Limits and defaults worth knowing
Check the current documentation before relying on an exact value; many of these are configurable.
| Message size | The maximum message size is 1 MiB. For large payloads, store the data in object storage and enqueue a reference, with an explicit lifecycle and access-control policy. |
|---|---|
| Message retention | Configurable from 60 seconds to 14 days; the default is 4 days. Retention is not indefinite archival storage. |
| Visibility timeout | The default is 30 seconds and the configurable range is 0 seconds to 12 hours. Extensions cannot move visibility beyond 12 hours from the original ReceiveMessage request. |
| Long polling | ReceiveMessage can wait up to 20 seconds. Configure the client's HTTP response timeout to exceed the chosen wait time. |
| Batch size | SendMessageBatch and DeleteMessageBatch accept up to 10 entries per request; ReceiveMessage returns up to 10 messages. Send batches also have an aggregate payload limit of 1 MiB. |
| Initial delivery delay | Queue delays and supported per-message timers range from 0 to 15 minutes. FIFO queues do not support per-message timers. |
Use it when
- A request should durably enqueue work and return before sending notifications, generating images, or running other slow tasks.
- Traffic arrives in bursts, and a bounded processing delay is acceptable while workers drain the backlog.
- Competing workers need durable task distribution without operating a broker cluster.
- Per-entity ordering is required, and FIFO message groups provide enough independent concurrency.
- Services need failure isolation, controlled retries, and a dead-letter path for work that cannot be processed.
Avoid it when
- Consumers need to replay historical events or maintain independent offsets over one retained log.
- Many independent subscribers must each receive every event, unless you add a fan-out layer and separate queues.
- The critical path requires an immediate synchronous answer rather than eventual task completion.
- The design requires global ordering and high parallel throughput at the same time, or assumes the queue alone can guarantee exactly-once business effects.
What interviewers ask about it
Follow-ups you can expect once SQS is on your whiteboard, and the core of a strong answer.
- What happens if a worker finishes the task and crashes before deleting the message?
- The message can be delivered again after visibility expires. Use a stable operation ID and make the business update and deduplication record atomic where possible; for an external provider, use its idempotency mechanism or reconcile uncertain outcomes.
- How would you choose the visibility timeout?
- Base it on observed processing time with enough margin for normal variation, then extend visibility for tasks that legitimately run longer. Too short causes overlapping attempts; too long delays recovery after a worker dies.
- Does a FIFO queue give you exactly-once processing?
- FIFO suppresses duplicate sends within its deduplication window and preserves ordering within message groups. It does not atomically commit your database or external side effect with message deletion, so application-level idempotency remains necessary.
- How do you reliably update a database and enqueue a message?
- Write the business change and an outbox entry in one database transaction, then have a relay publish the entry to SQS. A relay crash after sending but before recording success can publish a duplicate, so consumers still need idempotency.
- How do you scale workers without overwhelming a dependency?
- Use backlog per worker and oldest-message age to detect insufficient capacity, then cap concurrency against downstream capacity. Apply provider-specific rate limits and backoff rather than letting retries multiply load during an outage.
- What changes when failed FIFO messages move to a dead-letter queue?
- Removing a failed message lets later messages in that group proceed, which may violate the business sequence you intended to preserve. Decide whether skipping is acceptable; otherwise pause or quarantine the entity's workflow and repair it before continuing.
Common mistakes
- Deleting a message before its durable business effect succeeds, which turns a worker failure into lost work.
- Treating FIFO deduplication or a visibility timeout as proof that business effects happen exactly once.
- Choosing one MessageGroupId for all FIFO traffic and then expecting added workers to improve processing parallelism.
- Using one queue for independent subscribers, or treating completed queue messages as a replayable event history.
Alternatives
- Apache Kafka or Amazon MSK
- Choose a retained partitioned log when independent consumers need replay, offsets, and stream processing. Accept the additional partitioning, retention, and operational decisions.
- RabbitMQ
- Choose it when broker-level routing, exchange types, and messaging protocol flexibility matter more than SQS's managed simplicity.
- Amazon SNS with subscriber queues
- Choose this combination when every independent subscriber needs its own copy and retry lifecycle. SNS distributes events, while each SQS queue buffers work for one subscriber.
- AWS Step Functions
- Choose it when the core requirement is coordinating multi-step workflows, waits, branching, and compensation rather than simply distributing tasks.
Where it comes up
Interview questions where SQS is a natural fit, and why.
- Design a notification systemSQS provides per-channel work queues, bounded worker concurrency, and retry isolation for unreliable delivery providers.
- Design a video streaming service like YouTubeSQS can dispatch asynchronous transcoding tasks, while a separate workflow layer tracks dependencies and publication readiness.
- Design a distributed message queue like RabbitMQSQS is a concrete reference for visibility leases, explicit deletion, duplicate delivery, and dead-letter handling.
- Design a distributed job schedulerSQS can distribute due jobs to workers, while a durable scheduler handles long-term timing and recurring occurrences.
- Design Google PhotosSQS can buffer image-processing and indexing tasks after upload, using object references rather than media payloads.
- Design an on-call escalation system like PagerDutySQS can buffer notification attempts, while durable workflow state handles escalation deadlines and acknowledgement races.
Questions people ask
What is Amazon SQS used for?
Amazon SQS is used to buffer and distribute asynchronous work between services. Common examples include notification delivery, image processing, and background jobs where producers should not wait for processing to finish.
What is the difference between SQS Standard and FIFO queues?
Standard queues provide at-least-once delivery with best-effort ordering. FIFO queues preserve order within message groups and deduplicate sends within a five-minute window. Choose FIFO for a concrete ordering requirement, not as a replacement for idempotent consumers.
What is the difference between Amazon SQS and SNS?
SQS stores work for consumers to pull, and workers on one queue compete for messages. SNS publishes messages to subscribers and is commonly used for fan-out. Combining SNS with a separate SQS queue for each subscriber gives each service its own backlog and retry behavior.