Overview
Amazon SQS (Simple Queue Service) is a fully managed message queue. Standard queues provide nearly unlimited throughput, at-least-once delivery, and best-effort ordering; FIFO queues provide strict ordering within a message group and exactly-once processing (deduplication within 5 minutes) at lower throughput.
Consumers poll for messages; a received message becomes invisible for the visibility timeout. If the consumer deletes it, it is done; if not, it reappears for another attempt. After a configured number of receives, it moves to a dead-letter queue. SQS integrates with Lambda for serverless consumers.
Items wait on the shelf. When someone picks one up, it is reserved for them for a while. If they do not check it out in time, it goes back on the shelf for someone else.
When to use it
- Decoupling services on AWS without running brokers.
- Serverless background processing with Lambda.
- Buffering bursts in front of databases or APIs.
- Fan-out targets for SNS or EventBridge.
Where it shows up in interviews
Recognize it when: on AWS, process jobs without servers.
- Design an image thumbnail service
- Design an order processing pipeline on AWS
Recognize it when: events per account must be in order.
- Design a banking transaction processor
- Design inventory updates per SKU
Where it is used in real software
SQS was one of the first AWS services and underpins many internal decoupled systems.
Lambda polls SQS, invokes functions in batches, and scales concurrency with backlog.
Lambda can report individual failed messages so only those are retried.
Key terms
- Standard queue
- At-least-once, best-effort order, very high throughput.
- FIFO queue
- Ordered per MessageGroupId, deduplicated, limited throughput.
- Visibility timeout
- Time a received message is hidden.
- Long polling
- Wait up to 20 s for messages, reducing empty responses.
- Redrive policy
- maxReceiveCount before moving to a DLQ.
How it works, step by step
- 1Create queue and DLQ
Set visibility timeout > processing time and maxReceiveCount.
- 2Send messages
Up to 256 KB; use S3 for larger payloads.
- 3Receive with long polling
Batches of up to 10.
- 4Process idempotently
Duplicates can happen in standard queues.
- 5Delete on success
Otherwise the message reappears.
Standard vs FIFO
Choosing an SQS queue type
| Aspect | Standard | FIFO |
|---|---|---|
| Throughput | Nearly unlimited | 300 msg/s (3,000 with batching; higher in high-throughput mode) |
| Ordering | Best effort | Strict within MessageGroupId |
| Delivery | At least once | Exactly-once processing (5-min dedupe) |
| Use case | Thumbnails, emails | Ledger updates, per-user commands |
NOWAspect: Throughput | Standard: Nearly unlimited | FIFO: 300 msg/s (3,000 with batching; higher in high-throughput mode)
Use standard queues with idempotent consumers by default; use FIFO when order per entity is essential.
Implementation
import type { SQSEvent, SQSBatchResponse } from "aws-lambda"; // Lambda triggered by SQS: report only failed messages for retryexport const handler = async (event: SQSEvent): Promise<SQSBatchResponse> => { const batchItemFailures: { itemIdentifier: string }[] = []; for (const record of event.Records) { try { await processOrder(JSON.parse(record.body)); // idempotent by orderId } catch (err) { console.error("failed", record.messageId, err); batchItemFailures.push({ itemIdentifier: record.messageId }); } } return { batchItemFailures };};Complexity and performance
Extended client for S3 payloads.
Default 4 days.
Trade-offs
No brokers to run, but no replay, fan-out, or complex routing; combine with SNS or EventBridge.
Standard scales massively; FIFO gives order at lower throughput and requires group IDs.
Variants and related techniques
Postpone delivery up to 15 minutes.
One queue per subscriber service.
Common mistakes
- Visibility timeout shorter than processing time.
Fix: Messages are processed twice; set it longer or extend it during processing.
- No DLQ.
Fix: Poison messages loop forever; configure a redrive policy.
- One FIFO message group for everything.
Fix: Serializes all processing; group by entity ID.
Interview questions
How does SQS handle a consumer crash mid-processing?
The message was hidden for the visibility timeout; since it was never deleted, it becomes visible again and another consumer retries it. After maxReceiveCount failures it moves to the DLQ.
When do you choose SQS FIFO?
When processing order per entity matters, such as account transactions, and throughput per group is modest. Use MessageGroupId for the entity and dedupe IDs for exactly-once processing.
Practice problems
| Problem | Difficulty | What it trains |
|---|---|---|
| Build an S3 upload to SQS to Lambda thumbnail pipeline | Easy | Serverless async. |
| Design ordered per-account processing with FIFO | Medium | Message groups. |