# Using the message group ID with Amazon SQS FIFO Queues
<a name="using-messagegroupid-property"></a>

In FIFO (First-In-First-Out) queues, [https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_SendMessage.html](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_SendMessage.html) is an attribute that organizes messages into distinct groups. Messages within the same message group are always processed one at a time, in strict order, ensuring that no two messages from the same group are processed simultaneously. In standard queues, using `MessageGroupId` enables [fair queues](sqs-fair-queues.md). If strict ordering is required, use a FIFO queue. 

**Topics**
+ [

# Interleaving multiple ordered message groups in Amazon SQS
](interleaving-multiple-ordered-message-groups.md)
+ [

# Preventing duplicate processing in a multiple-producer/consumer system in Amazon SQS
](avoding-processing-duplicates-in-multiple-producer-consumer-system.md)
+ [

# Avoid large message backlogs with the same message group ID in Amazon SQS
](avoid-backlog-with-the-same-message-group-id.md)
+ [

# Avoid reusing the same message group ID with virtual queues in Amazon SQS
](avoiding-reusing-message-group-id-with-virtual-queues.md)

# Interleaving multiple ordered message groups in Amazon SQS
<a name="interleaving-multiple-ordered-message-groups"></a>

To interleave multiple ordered message groups within a single FIFO queue, assign a [https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_SendMessage.html](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_SendMessage.html) to each group (for example, session data for different users). This allows multiple consumers to read from the queue simultaneously while ensuring that messages within the same group are processed in order.

When a message with a specific `MessageGroupId` is being processed and is invisible, no other consumer can process messages from that same group until the visibility timeout expires or the message is deleted.

# Preventing duplicate processing in a multiple-producer/consumer system in Amazon SQS
<a name="avoding-processing-duplicates-in-multiple-producer-consumer-system"></a>

In a high-throughput, low-latency system where message ordering is not a priority, producers can assign a unique [https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_SendMessage.html](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_SendMessage.html) to each message. This ensures that Amazon SQS FIFO queues eliminate duplicates, even in a multiple-producer/multiple-consumer setup. While this approach prevents duplicate messages, it does not guarantee message ordering since each message is treated as its own independent group.

In any system with multiple producers and consumers, there is always a risk of duplicate delivery. If a consumer fails to process a message before the visibility timeout expires, Amazon SQS makes the message available again, potentially allowing another consumer to pick it up. To mitigate this, ensure proper message acknowledgment and visibility timeout settings based on processing time.

# Avoid large message backlogs with the same message group ID in Amazon SQS
<a name="avoid-backlog-with-the-same-message-group-id"></a>

FIFO queues support a maximum of 120,000 in-flight messages (messages received by a consumer but not yet deleted). If this limit is reached, Amazon SQS does not return an error, but processing may be impacted. You can request an increase beyond this limit by contacting [AWS Support](https://docs.aws.amazon.com/awssupport/latest/user/create-service-quota-increase.html).

FIFO queues scan the first 120,000 messages to determine available message groups. If a large backlog builds up in a single message group, messages from other groups sent later will remain blocked until the backlog is processed.

**Note**  
A message backlog can occur when a consumer repeatedly fails to process a message. This could be due to message content issues or consumer-side failures. To prevent message processing delays, configure a [dead-letter queue](sqs-dead-letter-queues.md) to move unprocessed messages after multiple failed attempts. This ensures that other messages in the same message group can be processed, preventing system bottlenecks.

# Avoid reusing the same message group ID with virtual queues in Amazon SQS
<a name="avoiding-reusing-message-group-id-with-virtual-queues"></a>

When using virtual queues with a shared host queue, avoid reusing the same [https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_SendMessage.html](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_SendMessage.html) across different virtual queues. If multiple virtual queues share the same host queue and contain messages with the same `MessageGroupId`, those messages can block each other, preventing efficient processing. To ensure smooth message processing, assign unique `MessageGroupId` values for messages in different virtual queues.