Shared queues are efficient until one tenant consumes a disproportionate amount of worker capacity. SQS Fair Queues introduce an interesting architecture option: preserve the shared queue while controlling noisy-neighbour dwell time.
Consider a parcel platform where many marketplace customers submit label-generation jobs through the same standard queue and worker fleet. One marketplace suddenly submits a large batch. The requirement isn't to punish that customer; it is to stop its backlog from unnecessarily increasing message dwell time for otherwise quiet customers.
Amazon SQS Fair Queues addresses exactly this multi-tenant problem. Producers attach a MessageGroupId representing the tenant, for example, customer ID. SQS detects tenants consuming a disproportionate share of consumer concurrency or processing time and temporarily prioritizes waiting messages belonging to quieter tenants. The noisy tenants messages are not discarded or rate-limited; their dwell time can increase while spare consumer capacity is directed toward quieter tenants.
This makes the architecture decision more nuanced than “create more consumers.” Additional consumers increase total capacity; Fair Queues address fairness within shared capacity. Separate queues are still preferable when customers need hard isolation, different retention/security controls, independently scaled consumers, or distinct SLAs.
**AWS added Fair Queues to standard SQS queues in July 2025, and AWS says they preserve standard-queue throughput while requiring no consumer-side change.
Top comments (0)