Load Balancer Visualizer
What is load balancing?
Load balancing routes each request to an eligible backend. A safe design must distribute work, eject unhealthy instances, preserve spare capacity, and prevent retries from multiplying an incident.
Step 1
Model
Change traffic, routing policy, affinity, backend capacity and weight, health ejection, and caller retry behavior.
Step 2
Observe
Trace request distribution, saturation, queueing, health ejection, availability, tail latency, and the consequence users experience.
Step 3
Challenge
Compare a node failure, slow instance, affinity hotspot, zone loss, retry storm, and gradual recovery. Find the policy that keeps failures isolated instead of moving pressure elsewhere.
Live routing workbench
Route traffic, then break the pool
Compare routing policy, backend pressure, health ejection, and the user impact of retries without hiding the failure path.
Availability
100.00%
0 user rps lost
Estimated p95
54.9 ms
routing plus queue delay
Queued
0 rps
attempts above capacity
Ejected
0 / 4
not eligible for new work
Retry load
+2%
1,275 total attempts
Request topology
Where every attempt goes
Line width represents routing share. Select a backend to tune its capacity and weight.
Failure laboratory
Inject a production condition
Active condition: Healthy
Two control loops
Separate routing intent from failure behavior
1. Traffic and routing
Arrival rate and algorithm change distribution before any health policy is applied.
2. Health and recovery
Ejection and retry policy determine whether a fault stays isolated or multiplies.
Selected backend
API A1Zone A
Healthy
73% utilized at 48 ms observed latency
Pool pressure
Distribution, saturation, and queueing
The marker at 100% is the tested capacity boundary.
API A1
Healthy
API A2
Healthy
API B1
Healthy
API B2
Healthy
Observed outcome
The pool is serving the declared traffic.
Users see stable response times and the fleet keeps usable headroom.
Raise traffic or change the algorithm to find the first pressure point.