Day 1: SQS Deep Dive

Phase 5 · Aug 12, 2026

Agenda (2–3 hours)

• Read (45 min): AWS SQS Developer Guide: Standard vs FIFO, visibility timeout, long polling, dead-letter queues
• Study (45 min): Design a SQS-based task queue: how does visibility timeout prevent double processing? When does a message go to the DLQ?
• Practice (45 min): Create a Standard and FIFO queue via CloudFormation; send 100 test messages; observe behavior with the AWS console
• Challenge (30 min): A consumer crashes after receiving a message but before deleting it. What happens? Design a visibility timeout strategy for variable-duration tasks

SQS Fundamentals

SQS is a fully managed message queue. Two types:

Visibility Timeout

When a consumer receives a message, it becomes invisible to other consumers for the visibility timeout (default: 30s).

If the consumer:

• Deletes the message: consumed successfully, removed from queue
• Crashes or times out: message becomes visible again for another consumer to receive
• Needs more time: call ChangeMessageVisibility to extend the timeout

Rule of thumb: visibility timeout = expected processing time × 6 (generous buffer).

// Extend visibility if processing is taking longer than expected
sqs.change_message_visibility()
    .queue_url(queue_url)
    .receipt_handle(receipt_handle)
    .visibility_timeout(120)  // extend by 2 more minutes
    .send().await?;

Dead Letter Queue Configuration

{
  "RedrivePolicy": {
    "maxReceiveCount": "3",
    "deadLetterTargetArn": "arn:aws:sqs:us-east-1:123456789:orders-dlq"
  }
}

After maxReceiveCount failed delivery attempts, message moves to DLQ.

DLQ must be the same type as the source queue (FIFO DLQ for FIFO source).

Always set a CloudWatch alarm: ApproximateNumberOfMessagesVisible > 0 on DLQ queues.

Long Polling

Short polling (default): SQS queries a subset of servers; may return empty even if messages exist.

Long polling: SQS waits up to 20s for a message before returning empty.

sqs.receive_message()
    .queue_url(queue_url)
    .wait_time_seconds(20)   // long poll
    .max_number_of_messages(10)
    .send().await?;

Long polling reduces API calls (and cost) by ~90% for low-volume queues. Always use it.

Key Takeaways

• Standard queue: maximum throughput, at-least-once, no ordering guarantee
• FIFO queue: strict ordering per MessageGroupId, exactly-once within 5-minute window
• Visibility timeout prevents double processing; extend it for long-running tasks
• Always configure a DLQ with CloudWatch alarm; use long polling to reduce API calls

Tomorrow: SQS consumer in Rust using the AWS SDK.