Noisy Neighbor

A noisy neighbor is one tenant on shared infrastructure whose resource use degrades everybody else's performance. Tenant isolation is about data, and the rule there is that one customer must never see another's rows. The noisy-neighbor problem is about capacity, and it survives perfect data isolation: processor time, memory bandwidth, disk throughput, connection-pool slots and database locks are all shared, so a single customer running an unbounded export or a badly indexed query can slow every other request on the same machine. The characteristic signature is a latency spike that correlates with nothing the team did. Deploys are clean, overall traffic is normal, error rates are fine, and the ninety-ninth percentile doubles for an hour. Aggregate dashboards hide it precisely because the noisy tenant is a small share of total requests while being a large share of one resource, which is why per-tenant attribution on the expensive dimensions is the instrumentation that turns an unexplainable spike into a name. Every defense is a form of admission control. Per-tenant rate limits and query timeouts stop one request from consuming an unbounded amount. Separate connection pools or worker queues for background work keep a slow export off the path serving interactive requests. Bulkheads dedicate a share of capacity to a class of work so exhaustion is contained rather than global. And the largest tenants are sometimes moved onto their own infrastructure, which solves the problem by ending the sharing and gives up the economics that made multi-tenancy attractive in the first place. The tempting response, adding capacity, usually buys time rather than a fix, because an unbounded operation scales with the tenant rather than with the size of the fleet.