Noisy Neighbor

A co-located workload consumes shared resources (CPU, I/O, memory, network bandwidth) at the expense of other tenants on the same host, database instance, or cluster, causing latency degradation that is invisible in the victim's own metrics but visible in shared infrastructure metrics.

Noisy neighbor is a multi-tenant resource contention problem. The critical property is that the victim workload is not doing anything wrong: it is operating within its own expected parameters. The cause is a co-tenant consuming a shared resource without limits.

Multi-tenant database: one tenant issues an analytical query (full table scan, complex aggregation) on a shared PostgreSQL instance. The query saturates shared_buffers and disk I/O. Other tenants on the same instance experience elevated query latency and connection delays: not because their queries are expensive, but because shared I/O is saturated. PostgreSQL provides no per-tenant resource isolation (statement_timeout helps, but is coarse).

Kubernetes without resource limits: a pod with no CPU limits bursts to consume all available CPU on the node when it has a traffic spike. Other pods on the same node are throttled by the CPU scheduler, experiencing latency spikes correlated with the noisy pod's activity: not their own. Setting CPU limits on all pods prevents this; the trade-off is that a pod cannot burst beyond its limit even if the node has spare capacity.

AWS EBS gp2 volumes: gp2 uses a credit-based I/O system. A volume bursts up to 3000 IOPS but accrues credits at a rate proportional to provisioned storage. Volumes that burst frequently drain their credit pool. This affects only the volume's own workload: not neighboring volumes. The noisy neighbor effect is within multi-tenant storage systems (NAS, SAN, shared NVMe) where I/O operations are shared.

Cloud instance type: c5.large instances share physical cores with other instances via hyperthreading and CPU time-slicing. A CPU-bound neighbor on the same physical host increases CPU steal time: the instance receives less CPU time than scheduled, causing latency spikes that appear as CPU saturation from the victim's perspective.

Shared Redis cluster: one application floods a Redis cluster with large keys or high-frequency SET operations. Redis being single-threaded means all other clients on the same Redis instance experience increased command latency during the flood.