SQS Standard vs FIFO Queues

Message queues decouple producers from consumers: a producer sends a message to the queue without waiting for a consumer to process it. The consumer processes messages at its own pace. This pattern prevents fast producers from overwhelming slow consumers, enables independent scaling of each tier, and provides a durable buffer if the consumer is temporarily unavailable. Amazon SQS is AWS's fully managed, highly available message queuing service.

Standard queues offer unlimited throughput (nearly unlimited transactions per second). They guarantee at-least-once delivery—a message may be delivered more than once in rare cases (due to distributed infrastructure). Message order is best-effort: messages are generally delivered in the order sent but not guaranteed. Standard queues are ideal when throughput is critical and your consumer can handle occasional duplicates and out-of-order delivery.

FIFO queues (First-In, First-Out) guarantee exactly-once processing and strict message ordering. Messages are delivered in the exact order they are sent. FIFO queues support up to 300 transactions per second (3,000 with batching). FIFO queue names must end with .fifo. Use FIFO queues when order and exactly-once semantics are critical—financial transactions, e-commerce order processing, inventory updates.

FIFO queues use Message Group IDs to partition ordering within the queue. Messages with the same Group ID are delivered in order; messages with different Group IDs can be processed in parallel. For example, use customerId as the Group ID: each customer's orders are processed in sequence, but different customers' orders are processed concurrently. This enables FIFO semantics with horizontal scalability across consumers.

FIFO queues prevent duplicate message processing using a deduplication ID. If two messages are sent with the same ID within a 5-minute deduplication interval, the second is silently discarded. You can provide a deduplication ID explicitly (MessageDeduplicationId) or enable content-based deduplication where SQS computes a SHA-256 hash of the message body as the deduplication ID automatically. Content-based deduplication is simpler but requires unique message bodies.

SQS retains messages for a configurable period: minimum 1 minute, maximum 14 days (default 4 days). Messages not consumed within the retention period are automatically deleted. The maximum message size is 256 KB. For larger payloads, use the SQS Extended Client Library or store the payload in S3 and send only the S3 object reference in the SQS message. Both Standard and FIFO queues share these limits.

Consumers poll the queue using receive-message. After receiving, the message becomes invisible (hidden from other consumers) for the visibility timeout period. The consumer must process the message and then explicitly delete it using the receipt handle before the timeout expires. If the consumer crashes or doesn't delete in time, the message reappears and another consumer can process it—enabling at-least-once delivery in Standard queues.

Standard queues are suitable for: image thumbnail generation, sending notification emails, log processing—workloads where duplicates can be handled idempotently and order doesn't matter. FIFO queues are required for: bank transfer processing (debit before credit), e-commerce cart updates (add item before checkout), workflow steps where step 2 must follow step 1. For most high-throughput architectures, Standard queues are the default choice; switch to FIFO only when ordering or exactly-once delivery is a hard requirement.

SQS charges per API request. Use batch operations to send, receive, and delete up to 10 messages per API call, reducing costs by up to 10x. FIFO queues support high-throughput mode (enabling batching) which raises the limit to 3,000 messages per second with batching of 10. Always use send-message-batch and delete-message-batch in production to minimise API call costs.

SQS queues are secured by resource-based policies (queue policies) that control who can send to or receive from the queue. This is critical when allowing cross-account access or when SNS publishes to an SQS queue. Lambda's access to SQS is controlled by the Lambda execution role's IAM policy (sqs:ReceiveMessage, sqs:DeleteMessage, sqs:GetQueueAttributes). Always apply least-privilege: don't give a consumer more than receive and delete permissions.

Ask these questions to choose: (1) Does order matter? If yes → FIFO. (2) Is exactly-once processing required? If yes → FIFO. (3) Is throughput above 3,000 TPS needed? If yes → Standard (FIFO caps at 3,000 TPS with batching). (4) Can consumers handle duplicates? If yes → Standard is simpler and cheaper. For the SAA-C03 exam, FIFO keywords are: 'ordering', 'exactly-once', 'sequential', 'deduplication'. Standard keywords are: 'high throughput', 'best effort', 'at-least-once'.

Test your understanding of AWS Solutions Architect (SAA-C03) concepts from this lesson.

In this lesson you learned: Standard queues offer unlimited throughput with at-least-once delivery and best-effort ordering, suitable for high-volume workloads that can tolerate duplicates, FIFO queues guarantee exactly-once processing and strict message ordering using Message Group IDs and deduplication IDs, capped at 3,000 TPS with batching, and choosing between them depends on whether ordering and deduplication are hard requirements. Next up we explore visibility timeout, dead-letter queues, and long polling.