Noisy tenants are a common problem in multi-tenant systems when one “noisy” tenant (customer) starts consuming a disproportionate amount of resources, such as CPU, memory, or queue capacity, or exceeding API limits. As a result, it affects other customers: latency increases, timeouts appear, session problems or downtime occurs.
How does this look in practice?
For example, you use a message broker (SQS, RabbitMQ, etc.), and one tenant generates a large number of events. Since the broker and event consumers are shared, they mostly process messages from the noisy tenant and other customers suffer from increased latency.
Another example is related to third-party integrations. You haven’t set clear per-customer rate limits and a noisy tenant calls the third-party API so frequently that it very quickly hits the rate limit and other clients can’t use the integration properly.
Main causes:
- Shared infrastructure: message brokers, databases, servers, etc.
- Shared limits of external services or a lack of rate limiting
- Uneven traffic distribution
Ways to solve the problems:
- Limits and fair resource allocation
- Quotas for heavy and expensive operations
- Dedicated resources for high-volume clients