Load Balancer Pool Capacity Calculator

Target demand:

Use representative steady-state traffic on the same RPS basis as every backend rating.

RPS

Planning utilization:

Choose the maximum sustained backend load you are prepared to plan around.

Backend pool:

CSV rows: name,max RPS,weight,health. Enter 1 to 12 uniquely named backends.

Growth buffer:

Keep zero for current traffic or enter the expected planning-horizon growth.

Failure reserve:

Use zero for the normal pool, one for N+1, or up to five for a bounded reserve check.

N+ backends

Display precision:

Use zero for whole-RPS planning or up to three decimal places for diagnostics.

digits

Measure	Value	Planning meaning	Copy
{{ row.label }}	{{ row.value }}	{{ row.note }}

Backend	Health	Share	Assigned RPS	Utilization	Pool ceiling	Note	Copy
{{ row.backend }}	{{ row.health }}	{{ row.share }}	{{ row.assigned }}	{{ row.utilization }}	{{ row.ceiling }}	{{ row.note }}

Check	Signal	Evidence	Next action	Copy
{{ row.check }}	{{ row.signal }}	{{ row.detail }}	{{ row.action }}

Adding backend throughput ratings does not always reveal how much traffic a load-balanced pool can carry. Routing weights decide each healthy backend's share. If that share is too large for a smaller server, the server reaches its planning limit while capacity on other servers remains unused.

Capacity planning should use a common requests-per-second (RPS) basis. Target demand, backend ratings, and load-test evidence need to represent the same request mix and sustained interval. A rating measured with cached reads cannot safely be compared with traffic dominated by slow database writes, even when both values are labelled RPS.

Maximum backend RPS: A measured sustained rate for one backend under the chosen workload.
Planning utilization: The share of that measured maximum allowed in the plan. A 70% target keeps 30% outside normal planned load.
Routing weight: A relative traffic share among serving backends. Equal weights give equal shares, not capacity-proportional shares.
Failure reserve: The weakest remaining capacity after removing the selected number of serving backends.

Health state matters as much as raw size. A down or draining backend should not contribute to the serving ceiling, and a maintenance plan should be tested with that backend already excluded. Growth belongs in modeled demand, while failure reserve belongs in the remaining-capacity test; combining them this way prevents a normal-pool pass from being mistaken for an N+1 pass.

This model is a feasibility estimate, not a latency guarantee. Connection limits, queueing, uneven sessions, slow requests, retries, database contention, autoscaling delay, and the load balancer itself can reduce useful capacity before a simple RPS ceiling is reached.

How to Use This Tool:

Use measurements from one representative traffic profile and one consistent observation window.

Enter Target demand and choose the highest sustained Planning utilization allowed for each backend.
Enter one Backend pool row per server as name,max RPS,weight,health. Names must be unique, and health must identify the row as serving or excluded.
Open Advanced to add a growth buffer or test N+1 through N+5 reserve. The reserve count must leave at least one serving backend.
Read the fit status and Weight-limited ceiling, then inspect the bottleneck backend and any weight gap before accepting the plan.

Interpreting Results:

Capacity ok means modeled demand is less than or equal to the normal weighted ceiling and, when selected, the failure-reserve ceiling.
Capacity short means modeled demand exceeds the normal pool ceiling. N+ reserve short means normal traffic fits but the selected failure case does not.
Weight gap is healthy planned capacity stranded by the routing-weight mix. A positive gap is a reason to compare weights with measured backend capacity, not an instruction to change production routing blindly.
Confirm the plan with load tests and production latency, error-rate, saturation, and queue-depth data. An RPS pass alone does not prove acceptable service quality.

Technical Details:

Only serving rows take part in weight normalization. Each serving backend receives a fraction of modeled demand equal to its weight divided by the total serving weight. Its own planned RPS limit is its measured maximum multiplied by planning utilization.

Formula Core:

The pool ceiling is the smallest total-pool demand that would bring any serving backend to its planning limit.

\begin{array}{lcl} D & = & D_{target} (1 + \frac{g}{100}) \\ s_{i} & = & \frac{w_{i}}{Σ w_{j}} \\ C_{i} & = & \frac{c_{i} u}{s_{i}} \\ C_{pool} & = & min_{i} (C_{i}) \end{array}

Load balancer pool capacity formula variables
Symbol	Meaning	Unit
D, D_target, g	Modeled demand, entered demand, and growth percentage	RPS, RPS, percent
w_i, s_i	Backend weight and normalized serving share	ratio
c_i, u	Measured maximum RPS and planning utilization as a ratio	RPS, ratio
C_i, C_pool	Backend-implied pool ceiling and final weight-limited pool ceiling	RPS

Assigned RPS for backend i is D multiplied by s_i. Backend utilization is assigned RPS divided by measured maximum RPS. Spare headroom is the pool ceiling minus modeled demand. The gross healthy ceiling sums every serving backend's planned limit; subtracting the weight-limited ceiling reveals the weight gap.

Rule Core:

Load balancer pool capacity rules and limits
Rule	Exact behavior
Health	Serving values include yes, up, healthy, enabled, active, true, and 1. Down, unhealthy, disabled, drain, draining, false, and 0 are excluded.
Backend rows	One to 12 non-empty CSV rows are accepted. Names must be unique; maximum RPS and weight must both be greater than zero.
Failure reserve	For N+k, every combination of k serving backends is removed. The lowest remaining weighted ceiling is reported.
Status boundaries	Spare RPS below 0 is short. Zero spare passes. A reserve with spare below 0 is short; zero reserve spare passes.
Display precision	Zero to three decimal places changes formatting only, not the underlying capacity values.

Accuracy Notes:

The calculation assumes weighted proportional routing and stable serving membership. It does not model least-connections behavior, sticky sessions, request-cost variation, connection reuse, health-check delay, queueing, or autoscaling. Use sustained backend ratings from representative tests and keep the health column aligned with the maintenance scenario being planned.

Worked Examples:

Equal servers just below target

Three serving backends rated at 850 RPS, each with weight 1 and a 70% planning target, contribute 595 planned RPS apiece. Their weighted pool ceiling is 1,785 RPS. Against 1,800 RPS of modeled demand, spare headroom is −15 RPS, so the normal pool is short even though the difference is small. An N+1 check would leave two servers and lower the worst remaining ceiling to 1,190 RPS.

References:

HTTP Load Balancing, NGINX Documentation.
Health checks for Application Load Balancer target groups, Amazon Web Services.
How to configure HTTP load balancing with HAProxy, Simplified Guide.
How to configure backend health checks in HAProxy, Simplified Guide.