SQS fair queues: MessageGroupId stops one client starving Sume jobs

If one SQS queue feeds Sume generation for several clients, set MessageGroupId to the client identifier on every message. On a standard queue that turns on SQS fair queues, which prioritizes quiet tenants when one tenant floods the queue, and it adds no ordering.

The Amazon SQS fair queues page (read 2026-10-10) says fairness applies automatically to standard queues for messages that carry a MessageGroupId, needs no consumer change, has no impact on API latency and adds no throughput limit. It also says the property on a standard queue is used only as a tenant identifier and does not enforce ordering, unlike on a FIFO queue.

The problem it solves for a Sume pipeline

An agency or platform that renders video for many clients usually puts all requests on one queue and one consumer fleet calls Sume. When one client submits a large batch, the consumers fill with that client's messages and everyone else waits. AWS calls this the noisy-neighbor effect and measures it as dwell time, the time a message spends in the queue before processing.

Sume has its own queue behind your consumers. Per the generation admission page, concurrency is a dispatch limit and not a submit limit: accepted jobs wait in queued until a workspace slot opens. On the Free plan that is 1 running plus 5 queued, so 6 accepted. A seventh submit gets 429 queue_full. Your SQS queue is the place where fairness between your own clients has to happen, because Sume sees one workspace.

How to wire it

Tag each message at the producer with the client id. Keep the consumer unchanged. Then make the consumer idempotent against Sume: derive the Idempotency-Key from the SQS message identity plus the client id, so a redelivered message after a visibility timeout returns the original job instead of a second paid job. The Sume docs say a retry with the same key returns the original job.

Do not use the group id as an ordering tool. If you need each client's jobs in order, that is a FIFO queue, where the same property means something different and the ordering rules apply.

• MessageGroupId = your client or project id, not a Sume job id.
• Idempotency-Key = stable per message, per client.
• Consumer concurrency at or below the plan's concurrency, so you do not hit queue_full.
• Treat 429 as a retry signal and honor retry-after.

What fair queues do not do

The page says SQS does not limit the consumption rate per tenant. If consumers have spare capacity and no other messages exist, a noisy tenant is still served. That is good for throughput, and it also means fair queues will not cap one client's spend. If a client must have a spending cap, put that check in your producer or use max_spend_usd on the call, which Sume enforces when you send it.

SQS also publishes CloudWatch metrics for quiet groups, such as a visible-messages metric limited to quiet groups. Compare them to the queue-level metrics when a client floods the queue: the queue backlog rises, while the quiet-group backlog should stay low. If it does not, check the consumer logs before blaming Sume, since Sume's own queue state is visible through the jobs reads.