Introduction
Imagine standing at a small one lane street. Only so many vehicles can pass you by. On a busy day at the manufacturing place next to you, you probably see more vehicles from that source than any other. An even larger supplier may send multiple vehicles on the road at one time, possibly blocking the street for normal traffic if there are no special rules how they enter the normal traffic. As you see, there should be rules (traffic lights) that restrict who is allowed to join the street now.
This is the problem that AWS SQS Fair Queues solve in the world of message processing.
AWS Simple Queue Service (SQS) Fair Queues is a feature that ensures messages are distributed evenly across message groups, preventing any single group from dominating queue processing. This capability is crucial for building fair, responsive, and predictable distributed systems.
The Problem: Message Group Monopolization

Here, the full consumer capacity (capable of processing all message colors) is utilized, but the noisy lavender colored producer starts to dominate the consumer resources due to a high volume of messages. This is creating a backlog not just for lavender message producers, but also impacting the red message producer and all others, reducing their throughput.
Why FIFO does not help here
FIFO queues maintain the order of messages. To keep this strict system working, the number of in-flight messages are restricted which limits the throughput for all producers. Fair queues maintain concurrent processing possibilities.
The Solution: Fair Queue Distribution & Implementation Details
You can assign a MessageGroupId on a message that is sent to SQS. This will activate Fair Queues and will identify noisy tenants by this id automatically. No further changes are needed on the producer or the consumer code.
SendMessageRequest request = new SendMessageRequest()
.withQueueUrl(queueUrl)
.withMessageBody(messageBody)
.withMessageGroupId("tenant-123"); // Tenant identifier
sqs.sendMessage(request);An example implementation is available in the aws-samples repository at https://github.com/aws-samples/sample-amazon-sqs-fair-queues/.
This will create 10 message groups and provide code to run a load test on the queue, one of the groups creates more messages than the other.

Running the example code we can see that the noisy group has been identified after a very short time and messages for this group are starting to get delayed. Note the metric of ApproximateNumberOfMessagesVisibleInQuietGroups which was stable over the entire process, showing that messages of the other groups were processed successfully without being blocked by the noisy group.
When to use and when to avoid Fair Queues
- Use on:
- Multi-tenant applications with varying load patterns
- Systems with multiple data sources of different volumes
- Applications requiring predictable processing times per group
- Scenarios where fairness is more important than raw throughput
- Systems with clear logical groupings of messages
- Avoid fair queues on:
- Single-tenant applications with uniform messages
- Systems where strict chronological ordering is critical
- High-throughput scenarios where every millisecond counts
- Applications with no clear message groupings
- Simple use cases where standard FIFO is sufficient
Conclusion
AWS SQS Fair Queues represent a powerful solution to the message group monopolization problem in distributed systems, by ensuring fair processing across message groups. They're ideal for multi-tenant systems and scenarios with varying message volumes. The trade-off is slightly reduced throughput for significant improved fairness.