4.1.1. Amazon SQS for Message Queues

First Principle: Amazon SQS provides a fully managed message queuing service that enables developers to decouple application components, improving fault tolerance, scalability, and asynchronous communication.

*3,000 msg/sec with batching

SQS lets you send messages between application components without them needing to be available at the same time. It's a key tool for decoupling microservices and building event-driven architectures.

• Fully Managed: No servers to provision or manage.
• Decoupling: Producers and consumers can operate independently, even if one is temporarily unavailable.
• Scalable: Handles any volume of messages.
• Reliable: Messages are stored redundantly across multiple servers.
• Standard Queues: (Default) Offer high throughput and at-least-once delivery. Messages can be delivered out of order.
• FIFO (First-In, First-Out) Queues: Guarantee exactly-once processing and maintain message order. Ideal for operations where order and uniqueness are critical (e.g., financial transactions).
• Dead-Letter Queues (DLQs): (A queue that other (source) queues can target for messages that can't be processed successfully.) Messages that fail to be processed by consumers can be automatically moved to a DLQ for later investigation.
• Message lifecycle: receiving a message doesn't delete it — it is hidden for the visibility timeout (default 30 seconds) so other consumers don't process it at the same time. The consumer must call DeleteMessage after processing; otherwise the message reappears, and after maxReceiveCount receives the redrive policy moves it to the DLQ.
• DLQ and visibility details: Setting maxReceiveCount in the source queue's redrive policy stops a poison-pill message from being retried forever. Lambda on-failure destinations cover asynchronous invocations and Kinesis, DynamoDB and Kafka event source mappings, but not an SQS event source mapping, so for an SQS trigger configure the DLQ on the queue. DeleteMessage takes the message's receipt handle, not its message ID. If processing outlasts the visibility timeout, the message reappears and is processed again, creating duplicates; for a Lambda trigger AWS recommends a visibility timeout of at least six times the function timeout (Lambda refuses to create the trigger if the function timeout exceeds the visibility timeout).
• Compare Amazon Kinesis Data Streams: Use it for ordered, replayable streams. Records with the same partition key stay in order within a shard and are retained (24 hours by default, up to 365 days) rather than deleted on read, so many consumer applications can read the same stream independently. Standard consumers pull (get a shard iterator, then call GetRecords); enhanced fan-out consumers have records pushed to them. Choose Kinesis over SQS when several independent consumers need the whole ordered stream (e.g., clickstream analytics).

Scenario: You're developing an e-commerce application. When a customer places an order, the frontend needs to respond immediately, but payment processing and inventory updates can happen asynchronously. You want to ensure orders are not lost if the backend processing service is temporarily unavailable.

⚠️ Exam Trap: SQS Standard queues allow at least once delivery (duplicates possible). SQS FIFO queues guarantee exactly once processing and order. If a question requires no duplicates, FIFO is the answer — but it has lower throughput (300 msg/sec without batching).