How Amazon SQS fair queues work - Amazon Simple Queue Service<br>View a markdown version of this page

How Amazon SQS fair queues work - Amazon Simple Queue Service<br>DocumentationAmazon Simple Queue ServiceDeveloper Guide<br>Tenant identificationHow detection worksHow message delivery order changesWhen a noisy neighbor becomes quietConsumer capacity considerations<br>How Amazon SQS fair queues work

Amazon SQS fair queues automatically mitigate the noisy-neighbor impact in multi-tenant queues<br>by preventing a single tenant from slowing down message processing for other tenants.<br>When fair queues detect that one tenant is using a disproportionate share of the<br>queue's consumer capacity, they prioritize delivery of messages from quiet tenants.

Tenant identification

Fair queues identify tenants by the MessageGroupId property on each message.<br>Messages that share the same MessageGroupId belong to the same tenant.<br>A fair queue can contain a mix of messages with and without a MessageGroupId.<br>Each message without a MessageGroupId is treated as belonging to its own distinct<br>tenant.

We recommend setting a MessageGroupId on every message you send to a fair queue,<br>using an identifier that maps to a real entity in your system, such as a customer ID,<br>client application ID, or request type.

How detection works

Amazon SQS detects noisy neighbors using two measures:

Concurrency share — the tenant's in-flight messages<br>as a fraction of all in-flight messages in the queue. This detects tenants with many<br>messages being processed at once, whether due to high send volume, slow processing,<br>or both.

Processing time share — the tenant's recent share<br>of total consumer processing time. This detects tenants whose messages are few in<br>number but slow to process, so the tenant occupies significant consumer time without<br>having many messages in flight at once.

A tenant is marked as a noisy neighbor when either of the following is true:

Concurrency share : the tenant accounts for more than<br>10% of in-flight messages in the queue and has at least 30 of its own messages in<br>flight.

Processing time share : the tenant's recent share of<br>total consumer processing time exceeds 10%.

Because Amazon SQS is a distributed system, these thresholds are approximate and detection may<br>not activate at the exact values described.

How message delivery order changes

Once a tenant is detected as a noisy neighbor, Amazon SQS prioritizes delivering messages from<br>quiet tenants. Consumer instances polling for messages receive messages from quiet tenants<br>whenever quiet-tenant messages are available. This prioritization continues until the noisy<br>neighbor's concurrency share and processing time share drop to levels comparable to quiet<br>tenants.

Noisy neighbor messages are not dropped or throttled. Their dwell time rises while<br>quiet-tenant messages are prioritized, and returns to normal once their backlog clears.<br>When no quiet-tenant messages are waiting, consumer instances receive noisy neighbor<br>messages as usual.

If multiple tenants are detected as noisy neighbors simultaneously, consumer instances receive<br>messages from the noisy tenant with the fewest in-flight messages first. This helps balance<br>processing time across noisy tenants.

When a noisy neighbor becomes quiet

A tenant is no longer treated as a noisy neighbor when either of the following is true:

The tenant's backlog has been fully consumed.

No messages from the tenant have been in flight for a continuous period of 5<br>minutes.

After that, the tenant's messages are no longer deprioritized and are treated the same as<br>messages from any other quiet tenant.

Consumer capacity considerations

For the concurrency share measure to work effectively, your consumers need to process enough<br>messages concurrently that one tenant's share of in-flight messages can stand out. Take this<br>into account when sizing your consumer fleet.

When using Lambda as a consumer through event source mapping, the number of in-flight messages<br>depends on both Lambda function concurrency and batch size. Evaluate these settings together<br>when sizing your consumers.

When the number of in-flight messages is too low for the concurrency share threshold to<br>trigger, the processing time share measure can still detect noisy neighbors. However, fair<br>queues work best when consumers process enough messages concurrently for both measures to be<br>evaluated.

Javascript is disabled or is unavailable in your browser.<br>To use the Amazon Web Services Documentation, Javascript must be enabled. Please refer to your browser's Help pages for instructions.

Document Conventions<br>Fair queues<br>Delay queues

Did this page help you? - Yes<br>Thanks for letting us know we're doing a good job!<br>If you've got a moment, please tell us what we did right so we can do more of it.

Did this page help you? - No<br>Thanks for letting us know this page needs work. We're sorry we let you down.<br>If you've got a moment, please tell us how we can make the documentation better.