Tenant Noisy Neighbor
criticalContainedmulti tenancy failure · fan out propagation
Blast Radius
0%
0/20 nodes
Time to Detect
30–120 seconds with per-tenant query rate and resource consumption metrics. Without per-tenant monitoring, the symptom appears as general platform degradation with no obvious single cause: investigation time extends to hours.
Preventive Mitigations
2
Confidence
StrongFailure Cascade
(no topology nodes mapped for this failure mode)
This failure mode is referenced in the scenario knowledge but has no connected topology nodes. Impact scope is scenario-level, all components should be considered potentially affected.
Severity at this step: critical
Detection Signals
Recovery time estimate: Immediate relief after terminating the noisy query (seconds). Resource recovery (buffer cache, connection pool) normalizes within 1–5 minutes. Long-term isolation via dedicated infrastructure takes days to weeks depending on migration complexity.
Mitigation Checklist(2 preventive, 2 reactive)
Identify tenants above a size or activity threshold and migrate them to dedicated database instances. This is the tiered isolation model: most tenants on shared, power users on dedicated. Eliminates the noisy neighbor problem for the most impactful tenants.
Apply per-tenant connection limits and statement_timeout (PostgreSQL: SET statement_timeout = '30s') on each tenant's connection. Long-running queries are automatically terminated before they saturate resources. Combine with per-tenant query QPS limits enforced at the connection proxy layer.
Route reporting and analytics queries to a read replica dedicated to analytics workloads. The primary and other replicas serving production traffic are isolated from the buffer cache pollution caused by large analytical scans.
Tenant isolation partitions resources between tenants so that one tenant's workload cannot consume resources allocated to others, eliminating the noisy neighbor problem.
Affected Systems
Workloads
Blast radius analysis is derived from structured topology and failure mode knowledge. It models structural propagation patterns, not measured production behavior. Actual incident scope depends on runtime conditions, traffic, and recovery actions in place at the time of failure.