Amazon SQS: Queues, Visibility & DLQs

SQS decouples producers from consumers with a durable queue

Amazon Simple Queue Service (SQS) stores messages until consumers receive and delete them, allowing producers and consumers to run at different rates and fail independently. This is a pull-based decoupling pattern: consumers call ReceiveMessage or a managed integration polls on their behalf. The queue absorbs temporary bursts so a downstream worker fleet can process work according to available capacity.

Standard queues provide at-least-once delivery and best-effort ordering. Applications using them must therefore make processing idempotent and tolerate messages arriving more than once or in a different order. FIFO queues add strict ordering within each message group and deduplication semantics for workloads that require ordered processing, trading some flexibility for stronger delivery behavior.

Visibility timeout coordinates in-flight work

When a consumer receives a message, SQS marks it in flight and hides it from other consumers for the visibility timeout. If processing completes, the consumer deletes the message using its receipt handle. If processing fails or takes longer than the visibility period without an extension, the message can become visible again and another consumer may receive it. Visibility is therefore a temporary lease, not a lock that proves processing succeeded.

The timeout should cover normal processing time while still allowing failed work to return to the queue promptly. Consumers can change a message's visibility while processing when duration is variable. With Lambda event-source mappings, the queue visibility setting must also be chosen around the function timeout and retry behavior according to Lambda's SQS integration guidance.

• Visibility timeout starts when a message is received.
• DeleteMessage is the acknowledgement that removes successfully processed work.
• Long polling waits for messages and reduces empty/false-empty receive responses.
• Delay queues hide newly sent messages; visibility timeout hides already received messages.

DLQs isolate poison messages; FIFO groups define ordering scope

A source queue can use a redrive policy with a dead-letter queue. After a message has been received unsuccessfully enough times to cross the configured maxReceiveCount, SQS moves it to the DLQ. This prevents a repeatedly failing message from consuming normal processing cycles forever and gives operators a place to inspect, correct, or redrive problematic work. AWS requires the DLQ to use the same queue type as its source and recommends keeping it in the same account and Region.

For FIFO queues, MessageGroupId is the ordering boundary. Messages in one group are processed in strict sequence, while different groups allow parallelism. MessageDeduplicationId or content-based deduplication prevents duplicate sends within the FIFO deduplication window. This is not a reason to abandon idempotency: applications can still experience retries and downstream side effects, so business operations should be safe to repeat where practical.