SQS Standard vs. FIFO: Speed vs. Order

When you create an SQS queue, you make a permanent, irreversible choice between two queue types. You cannot convert a Standard queue to FIFO after creation. Understanding the trade-offs is critical.

1. Standard Queues (The Default)

Standard queues are designed for maximum throughput. AWS makes no strict guarantees about ordering or duplicate delivery in exchange for near-unlimited scale.

• Throughput: Effectively unlimited — tens of thousands of messages per second per queue.
• Ordering: Best-Effort Ordering. Messages usually arrive in the order they were sent, but occasionally a message may arrive out of sequence. Do not rely on order.
• Delivery: At-Least-Once Delivery. Occasionally, a message may be delivered more than once. Your consumer application must be idempotent — processing the same message twice must produce the same result as processing it once. For example, "set user status to ACTIVE" is idempotent; "increment user's login count by 1" is not.
• Use Cases: Video transcoding jobs, bulk email campaigns, log aggregation, decoupled microservices where strict ordering is not required.

2. FIFO Queues (First-In-First-Out)

FIFO queues sacrifice raw throughput for strict guarantees. The name describes the core promise: the first message in is the first message out.

• Throughput: 300 messages per second (TPS) by default. Up to 3,000 TPS when using batching (sending/receiving up to 10 messages per API call).
• Ordering: Strictly Preserved. Message 1 will always be processed before Message 2 within the same Message Group ID (a grouping key you assign).
• Delivery: Exactly-Once Processing. SQS deduplicates messages within a 5-minute window using a Deduplication ID you provide (or a SHA-256 hash of the message body if you enable content-based deduplication).
• Naming: The queue name must end with .fifo (e.g., transactions.fifo).
• Use Cases: Bank transactions (a deposit must be recorded before a withdrawal against that deposit), e-commerce order state machines (payment before fulfillment), inventory management.

The Idempotency Requirement for Standard Queues

Idempotency is not optional when using Standard queues — it is a design requirement. Common techniques include:

• Database unique constraints: Before processing, insert a record with the message ID as the primary key. If the insert fails (duplicate), skip processing.
• Conditional writes: Use DynamoDB's ConditionExpression to only write if an item doesn't already exist.
• Idempotent operations by design: Prefer "set X to value Y" over "add Y to X".