Comparison: Amazon SQS FIFO vs Standard Queues

Amazon SQS offers two types of message queue. A FIFO queue delivers messages in the order they were sent and suppresses duplicates, capped at a few thousand messages per second. A standard queue has effectively unlimited throughput but only best-effort ordering and at-least-once delivery, so consumers have to tolerate duplicates.

Sending webhooks?

Svix is the enterprise-ready webhook sending service. It handles signing, retries, and delivery observability, so you can ship a reliable webhook platform in minutes instead of months. Start sending webhooks with Svix.

How the two queue types differ

FIFO queues

Every message sent to a FIFO queue carries a MessageGroupId, and SQS delivers the messages in a group strictly in order, holding the next one back until the current message is deleted or its visibility timeout expires. Groups move independently of each other, so the group ID is also how you get parallelism: one group per customer or per account preserves ordering where it matters without serializing the entire queue.

Deduplication is time-boxed rather than absolute. SQS discards a repeat of the same deduplication ID within a five-minute window, which covers a retried send but not a duplicate produced an hour later, so idempotent consumers are still worth writing. Throughput is the other tradeoff: the default quota is 300 API calls per second per action, or 3,000 messages per second when you batch ten at a time, and turning on high throughput mode raises that considerably with the exact ceiling set per region. FIFO earns its cost when order is part of correctness, as in bank transfers or a state machine where an update must not overtake the record it depends on.

Standard queues

Standard queues trade both guarantees for speed. Throughput is effectively unlimited, delivery is at-least-once, and ordering is best-effort: messages usually arrive in the order they were sent, but a redelivered message can land after newer ones. That suits log ingestion, analytics events, thumbnail generation, and anything else where each message stands alone. The duplicate handling has to live in the consumer, usually as an idempotency key checked before the work runs, and deliveries that keep failing should land in a dead-letter queue rather than cycling forever.

Creating and using each queue type

Creating a standard queue

import boto3

sqs = boto3.client('sqs')

# Create a standard queue
standard_queue = sqs.create_queue(QueueName='MyStandardQueue')

Creating a FIFO queue

Note: FIFO queue names must end with the .fifo suffix.

# Create a FIFO queue
fifo_queue = sqs.create_queue(
    QueueName='MyFifoQueue.fifo',
    Attributes={'FifoQueue': 'true'}
)

Sending messages to a FIFO queue

FIFO queues require a MessageGroupId.

response = sqs.send_message(
    QueueUrl=fifo_queue_url,
    MessageBody='Your message',
    MessageGroupId='messageGroup1'
)

Receiving and deleting messages

The process of receiving and deleting messages is similar for both queue types.

messages = sqs.receive_message(QueueUrl=queue_url, MaxNumberOfMessages=10)
for message in messages.get('Messages', []):
    # Process the message
    sqs.delete_message(QueueUrl=queue_url, ReceiptHandle=message['ReceiptHandle'])

Choosing between FIFO and standard queues

Start from standard and move to FIFO only when you can name the ordering that would break. Most workloads that feel order-sensitive are really duplicate-sensitive, and an idempotency key in the consumer solves that on a standard queue without the throughput ceiling or the group-ID design work. If you do need order, scope it narrowly with a group ID per entity so one slow consumer does not stall unrelated messages. For how SQS compares to other brokers on these guarantees, see Kafka vs SQS and RabbitMQ vs SQS.

The same question comes up when you send events to customers over HTTP, where retries mean a receiver can see an event twice or out of order. [Svix]https://www.svix.com/?utm_source=resources&utm_medium=content) handles that side, delivering webhooks with retries, signatures, and delivery logs so your consumers only need to be idempotent.