A B2B SaaS platform processes background jobs — report generation, data exports, invoice creation — through a single SQS Standard queue (message queue, all messages compete equally for consumer capacity). There are 40 tenants sharing the queue. Each message carries a <code>tenant_id</code> field. Ten worker processes consume from the queue at a combined throughput of 800 messages per minute.
For most tenants, jobs complete within 2–3 minutes of submission. The architecture has been stable for two years.
Last Tuesday, Tenant <code>enterprise-07</code> ran their quarterly data export: 50,000 messages submitted over 20 minutes. The other 39 tenants submitted a combined 3,100 messages in that same window.
For the duration of the export, every other tenant’s jobs waited 18–25 minutes. Three tenants with 5-minute SLAs breached. Two of them escalated to your account manager.
Your team proposes splitting into two queues: one dedicated to <code>enterprise-07</code>, one for everyone else. It would work. But you have 40 tenants today and a sales pipeline with 200 more.
What is the correct fix?
A) Split into two queues now and build a queue-per-tenant provisioning system for future growth — works at 40 tenants, becomes 240 queues, 240 consumer pools, and a provisioning system you now own at 240
B) Switch to SQS FIFO (First-In-First-Out queue, enforces ordering within MessageGroups — does not implement fairness across groups) with one MessageGroupId per tenant — <code>enterprise-07</code>’s messages still dominate because they are the majority of messages in the queue
C) Enable SQS Fair Queues (Standard queue feature — tracks in-flight count per MessageGroupId, deprioritizes noisy groups in real time) on the existing Standard queue and set <code>MessageGroupId</code> to <code>tenant_id</code> on every message
D) Scale consumers from 10 to 50 workers — <code>enterprise-07</code> still accounts for 94% of messages; 94% of 50 new workers spend their time on one tenant; small tenant wait times drop marginally but the SLA breach continues
Answer in the comments.
#AWS #SystemDesign #DistributedSystems #SoftwareArchitecture #MultiTenancy

Joud Awad

A scenario-based system design puzzle walks through a multi-tenant SaaS platform whose shared SQS Standard queue gets monopolized by one tenant's 50,000-message bulk export, starving other tenants and breaching SLAs. Four proposed fixes are evaluated: splitting queues per tenant (doesn't scale to 200+ tenants), switching to SQS FIFO with per-tenant MessageGroupId (doesn't fix fairness since ordering isn't fairness), scaling consumer count (doesn't help when one tenant dominates message volume), and enabling SQS Fair Queues with MessageGroupId set to tenant_id, which throttles noisy tenants in real time without per-tenant queue provisioning.

Day 22/30 AWS System Design Patterns

The answer is C.
AWS launched SQS Fair Queues (Standard queue feature — tracks in-flight count per MessageGroupId, deprioritizes noisy groups in real time) in July 2025. It runs on Standard queues — not FIFO — and solves the noisy neighbor problem at the queue layer without restructuring your architecture.
When you enable Fair Queues and set <code>MessageGroupId</code> on messages, SQS (message queue) tracks in-flight message counts per group in real time. When one group’s count grows disproportionately — <code>enterprise-07</code> sending faster than consumers can process — SQS identifies it as a noisy neighbor and deprioritizes its messages, actively pulling from the other groups instead. The moment <code>enterprise-07</code>’s in-flight count dominates, SQS starts favoring the 39 other tenants until their backlogs drain. No code changes in consumers. No new infrastructure.
<img src="https://media.daily.dev/image/upload/s--o0504-Yz--/f_auto/v1786615430/ugc/content_2afbbbfd-e00a-4d33-a1e4-452431948840?_a=BAMAMicg0" alt="ChatGPT Image Aug 13, 2026, 01_03_10 PM.png">

ohh great I did not know that SQS support this feature! nice share man

C is the scalable fix here. Using tenant_id as MessageGroupId gives SQS the signal it needs to reduce noisy-neighbor impact without multiplying queues and worker pools. I’d still alert on per-tenant age-of-oldest-message so fairness problems stay visible.

A — Queue-per-tenant works at 40 tenants. At 240 it becomes an operational problem: 240 queues, 240 consumer pools, 240 alarm configurations, and a provisioning system you now own and maintain. You’ve moved the problem from SQS into your own infrastructure.