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">

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.

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.

B — SQS FIFO (First-In-First-Out queue, enforces ordering within groups) with one MessageGroupId per tenant enforces ordering within each group and prevents parallel processing of the same tenant’s messages. It does not implement fairness across groups. <code>enterprise-07</code>’s messages still dominate consumer capacity because they are the majority of messages in the queue. FIFO throughput defaults to 300 API calls per second per action — 3,000 messages/second with batching — and high-throughput mode raises that ceiling dramatically; but no throughput mode adds fairness across groups, which is the actual requirement.