TENANT CAPACITY · PARTITIONS
Tenant capacity: scale the constrained partition
Let one tenant burst on a shared partition, then compare uniform scaling, targeted scaling, isolation and a per-tenant rate limit.
Event trace
Computed data
Final metrics
Discrete one-second simulation for 30 s: each request needs one worker for one second, queues hold 20 per partition, and arrivals from different tenants interleave. Requests still queued at the end count as timed out. The +8 worker budget is the same for every scaling action. Autoscaling delay, retries and cost are not modeled.
A noisy neighbour
Tenant A sends 2 requests per second on partition P1; tenant B sends 10 and tenant C 2 on partition P2. With 4 workers per partition, P2 receives 12 requests a second for 4 workers. B loses 224 requests to a full queue, and C, which only shares the partition, completes 52 of 60: NOISY NEIGHBOR, C 87%, B 23%, A 100%. P1 is busy only 50% of the time.
Spend the same 8 workers differently
Scaling action +4 workers on every partition lifts C to 97% and B to 61%, HOT TENANT CONTAINED, but half the new capacity lands on P1, whose utilisation falls to 25%. +8 workers on P2 gives P2 12 workers for 12 requests a second: ALL TENANTS SERVED. Move B to a new partition with 8 workers protects C completely, 100%, while B, at 10 requests for 8 workers, completes 80%.
Limit the tenant instead
Without scaling, a Tenant B rate limit of 2 per second leaves P2 with exactly its capacity: C 100%, and B completes 20% because the rest is rate-limited at admission. A limit of 6 still overloads P2, so C stays at 87%; the rejections move from the queue to the limiter. At a Tenant B request rate of 2, everyone is served.
Workers and timeouts
10 workers per partition gives C 97% and B 81%; 1 worker starves everyone, even A, at 50%. A Request timeout of 1 s drops waiting requests sooner and frees queue slots, which lifts C to 97%; the table shows the extra timeouts. Per tenant it lists sent, completed, rate-limited, queue-full and timed-out requests and the average wait.
Replay and limits
Any change recomputes the run and rewinds it; the Complete-run preview states the outcome at once. Play and Pause walk through the events, Next event jumps one event, Restart rewinds, Speed runs from 0.25x to 2x and Inspection time seeks from 0 to 60 seconds, where the outcome and final metrics appear. A one-second simulation for 30 s: each request needs one worker for one second, queues hold 20, arrivals from tenants interleave and requests still queued at the end count as timed out. Autoscaling delay and retries are not modeled.