What ratio of unbalanced in-flight messages and number of consumers are needed to trigger SQS Fair Queues?

Hi there. I been testing this feature and I can't make it work.

I have 3 different logical entities, each one pushing messages to their group id.

In one of them I push 10.000 messages and while this messages are being processed I push 3 messages to another group id and 200 to a 3rd different group id

My consumer is a lambda with concurrency set to 2.

The behaviour I expect and I'm not observing is that these 3 messages must be processed while the 10.000 are being processed and the consumer shouldn't wait until all of this messages are done to process these 3 messages.

Is there any extra configuration I should set up so that this fairness logic kicks in?

Based on the available information, Amazon SQS fair queues automatically detect noisy neighbors by monitoring the distribution of in-flight messages across tenants during processing. However, the specific ratio that triggers the fair queue mechanism is not explicitly stated in the documentation.

What we do know is that Amazon SQS identifies a tenant as "noisy" when it has a disproportionately large number of in-flight messages compared to other tenants. The system continuously monitors this distribution to make these determinations. When a significant portion of consumer resources is occupied by one tenant, that tenant is identified as noisy.

Regarding the minimum number of consumers needed for fair queues to be effective, the documentation doesn't specify an exact number. Your observation that fair queues seem to work better with more consumers aligns with the general principle that the feature is designed to address resource allocation across multiple consumers, but there's no stated minimum threshold.

For your question about how Horizontal Pod Autoscaling (HPA) in Kubernetes might impact fair queues' detection of noisy neighbors, the documentation doesn't directly address this interaction. However, since fair queues work by monitoring in-flight message distribution and prioritizing delivery to maintain low dwell times for quiet tenants, scaling up consumers based on queue depth would likely help process the overall backlog faster, potentially reducing the impact of noisy neighbors naturally. The fair queue mechanism would continue to operate regardless of scaling events, prioritizing messages from quiet tenants while still allowing messages from noisy tenants to be processed when capacity is available.

To monitor the effectiveness of fair queues in your environment, you can use the CloudWatch metrics like ApproximateNumberOfNoisyGroups, ApproximateNumberOfMessagesVisibleInQuietGroups, and compare them with standard queue-level metrics to understand the impact of noisy tenants and how well the fair queue mechanism is mitigating it.
Sources
Amazon SQS fair queues - Amazon Simple Queue Service
Amazon SQS introduces fair queues for multi-tenant workloads - AWS
Building resilient multi-tenant systems with Amazon SQS fair queues | AWS Compute Blog

What ratio is considered disproportionate? SQS automatically monitors inflight message distribution and detects when a single group is consuming a disproportionate share of processing capacity or when the queue backlog reaches certain levels. These thresholds are dynamically tuned as AWS continues to optimize the system's quality of service.

How many consumers do I need for Fair Queues to kick in? This depends on the setup and how the consumption is configured. It's possible to trigger the tenant isolation with multiple noisy neighbors from a single machine. If setup with Lambda via ESM is used, then consumer concurrency should be evaluated together with batch size to determine the values sufficient for the tenant isolation algorithm to activate in a noisy neighbor scenario. You can refer to the sample code on GitHub[+] for implementation examples.

[+] https://github.com/aws-samples/sample-amazon-sqs-fair-queues

In a k8s setup, how will HPA impact Fair Queues detection?" Fair Queue is a feature of Standard queues. They do not limit the throughput of your queue and have no impact on API latency. SQS does not limit the processing throughput per tenant, including noisy neighbors. As long as you have enough consumer capacity, you will still receive noisy neighbor messages.

The AWS documentation is continually being improved to provide more details on how this feature works.