Load Balancer Pool Capacity Calculator

{{ result.statusText }} Bottleneck: {{ result.bottleneckLabel }} {{ result.healthyBadge }} {{ result.weightBadge }}

Target demand:

Enter steady-state demand before any optional growth buffer.

RPS

Planning utilization:

Use the sustained ceiling you are comfortable running, such as 65-80%.

Backend pool:

CSV rows: backend name, max RPS, routing weight, health flag.

Review pool inputs

{{ error }}

Growth buffer:

Leave at 0 for current demand only; use 10-30% for planned growth.

Failure reserve:

Use 0 for no failure reserve, 1 for N+1, or 2 for N+2 planning.

N+ backends

Display precision:

Use 0 for whole-RPS planning or 1-2 for closer diagnostic exports.

digits

Aspect	Value	Details	Copy
{{ row.aspect }}	{{ row.value }}	{{ row.details }}

Backend	Health	Share	Assigned RPS	Max RPS	Utilization	Spare	Pool ceiling	Note	Copy
{{ row.backend }}	{{ row.health }}	{{ row.share }}	{{ row.assignedRps }}	{{ row.maxRps }}	{{ row.utilization }}	{{ row.spare }}	{{ row.poolCeiling }}	{{ row.note }}

Check	Signal	Detail	Action	Copy
{{ row.check }}	{{ row.signal }}	{{ row.detail }}	{{ row.action }}

Export to PDF Fullscreen

Embed:

Customize

Include current inputs

Size

Advanced

Width

Height

Aspect ratio

Max height

Collapsible embed

Allow fullscreen

Referrer policy

Sandbox tokens

Load balancer pool capacity is the request rate a backend group can carry before one serving node reaches the planning limit. The useful number is not always the sum of all backend maximums, because routing weights can send too much traffic to a smaller node while larger nodes still have room. Capacity planning asks whether the pool can serve the expected requests per second (RPS) with enough spare headroom for growth, maintenance, and failures.

Backend pools are often planned from two different views. The raw view adds the maximum RPS from healthy backends and then applies a target utilization, such as 70%. The weighted view checks how traffic is actually shared. If each backend has equal weight, an undersized backend may become the first saturated member and set a lower pool ceiling than the raw total suggests.

Diagram of modeled demand split by routing weights into healthy and excluded load balancer backends

Health status changes the estimate as much as size and weight. A backend that is down, draining, disabled, or invalid should not be counted as serving capacity. In real production systems, health checks, connection draining, warm-up behavior, and uneven request cost can make actual traffic less tidy than a static planning model, so the result should be treated as a capacity estimate that needs monitoring and load-test evidence behind it.

The most useful answer is often the gap, not the ceiling. Positive spare headroom means modeled demand fits under the current planning limit. Negative spare headroom means the target demand is above the modeled pool ceiling, even if the raw sum of backend maximums looks large enough.

Technical Details:

Weighted load balancing assigns a fraction of request demand to each serving backend. With total healthy weight W, a backend with weight w_i receives w_i / W of the modeled demand. The backend also has a planned serving ceiling, which is its maximum RPS multiplied by the selected target utilization.

The pool ceiling is set by the first healthy backend that would reach its planned serving ceiling under the current weight split. This is why a pool can have stranded capacity. If a small backend receives the same weight as a larger backend, the smaller backend can cap the whole pool while spare capacity remains on the larger nodes.

Formula Core:

The calculation compares every serving backend's own ceiling against its weight share, then uses the smallest resulting pool value.

\begin{array}{lll} D & = & D_{target} \times (1 + growth) \\ S_{i} & = & \frac{w_{i}}{W} \\ C_{i} & = & \frac{R_{i} \times u}{S_{i}} \\ C_{pool} & = & \min (C_{i}) \\ spare & = & C_{pool} - D \end{array}

Load balancer capacity variables and meanings
Symbol or term	Meaning	Unit or boundary
`D`	Modeled demand after the optional growth buffer is applied.	RPS, zero or higher
`R_i`	Maximum RPS for a serving backend row.	Positive RPS
`w_i`	Routing weight for a serving backend row.	Positive number
`u`	Planning utilization expressed as a fraction.	1% to 100%
`C_i`	Total pool RPS at which backend `i` reaches the planning utilization.	RPS
`C_pool`	Weight-limited ceiling for the whole serving pool.	Smallest backend ceiling

Gross healthy ceiling is a second, less restrictive view. It adds the maximum RPS from all healthy and valid backends, then multiplies by the target utilization. The difference between gross healthy ceiling and weight-limited ceiling is reported as a weight gap when routing weights leave usable capacity stranded behind a bottleneck backend.

Capacity output fields and interpretation
Output field	What it means	Interpretation cue
`Modeled demand`	Target RPS after adding the growth buffer.	Compare this directly with spare headroom and reserve spare.
`Weight-limited ceiling`	Maximum modeled pool RPS before a serving backend reaches the selected utilization.	The central capacity number for the current weight split.
`Gross healthy ceiling`	Sum of healthy backend max RPS multiplied by planning utilization.	Useful for seeing capacity that weights may not use.
`Spare headroom`	Weight-limited ceiling minus modeled demand.	Negative values indicate a modeled shortfall.
`Peak backend utilization`	Highest modeled utilization among serving backends at the entered demand.	Values above the target show demand beyond the planning ceiling.
`N+ reserve ceiling`	Lowest remaining ceiling after removing the selected count of healthy backends.	Use it only when failure reserve is enabled.

N+ reserve is modeled conservatively. For N+1, one healthy backend is removed and the remaining pool is recalculated. For N+2, two are removed. The reported reserve ceiling is the lowest remaining capacity found among the tested removal sets, with a fallback to the largest backends first when a very large combination set would be impractical.

Only healthy, valid backend rows participate in capacity. Accepted healthy flags include values such as yes, up, healthy, enabled, and 1. Values such as no, down, disabled, drain, draining, and 0 are excluded from serving capacity. Unrecognized health text is treated as down and shown as a validation issue.

Everyday Use & Decision Guide:

Start with steady-state demand in Target demand, a planning ceiling in Planning utilization, and one CSV row per backend in Backend pool. A practical first pass is to use measured or load-tested per-backend maximum RPS, production routing weights, and current health state. If you only have rough numbers, keep the utilization conservative, then revisit the result after a small load test.

The backend CSV format is simple: backend name, max RPS, routing weight, and health flag. Keep weights in the same proportion used by the load balancer. Equal weights are fine for identical nodes, but they can create a bottleneck when one backend has less capacity than the others. After results appear, Backend Allocation shows share, assigned RPS, utilization, spare, and each row's pool ceiling so the weak point is visible.

Use Growth buffer when planning the next traffic horizon. Set it back to 0 when checking only current demand.
Use Failure reserve for N+1, N+2, or similar reserve checks. If N+ reserve short appears, the current pool fits normal demand but not the selected failure case.
Use Display precision to choose whole-RPS or decimal output for tables and JSON. It changes presentation, not the capacity model.
Open Pool Capacity Envelope to compare modeled demand, weight-limited ceiling, gross healthy ceiling, and reserve ceiling when enabled.
Open Backend Saturation Map to see which serving backend is closest to, or beyond, the planning utilization line.

The fastest trust check is the summary box. Capacity ok means modeled demand fits the current weight-limited ceiling. Capacity short means demand is above the modeled ceiling. N+ reserve short means normal demand fits but the selected reserve case does not. A healthy badge such as 3/4 serving should also be checked before relying on the ceiling.

Do not treat spare headroom as a latency or error-rate promise. A pool can fit the RPS model while still failing from database waits, slow endpoints, large request mix changes, connection limits, or uneven availability-zone traffic. Use the calculator to find the capacity gap, then confirm the result with load balancer metrics and backend saturation under representative traffic.

Step-by-Step Guide:

Enter the demand and backend rows first, then use the advanced controls only when the base case is clear.

Enter Target demand in RPS. The Pool Snapshot tab will later show it as Modeled demand, with growth included if you add a buffer.
Set Planning utilization to the sustained backend load you are willing to plan around, such as 70 for a 70% ceiling.
Paste backend rows into Backend pool using name,max RPS,weight,health. Fix any Review pool inputs messages before trusting the result.
Open Advanced and set Growth buffer if the demand forecast needs future traffic included in the current pass.
Set Failure reserve to 0 for the normal pool, 1 for N+1, or 2 for N+2. The Pool Snapshot tab adds reserve rows only when this value is above zero.
Read Weight-limited ceiling, Spare headroom, Serving backends, and Peak backend utilization before moving to charts.
Use Backend Allocation to identify the row whose Pool ceiling or utilization explains the bottleneck badge.
Use Capacity Guidance for the recommended next action, especially when it reports Short, Bottleneck, Reduced pool, or a failed reserve check.

Finish by saving the table, chart, or JSON view that matches the decision you are documenting: pool fit, backend allocation, capacity guidance, capacity envelope, or saturation map.

Interpreting Results:

Read Weight-limited ceiling as the planned RPS ceiling for the current healthy weighted pool. Read Gross healthy ceiling as the theoretical healthy sum at the same utilization. If the gross number is higher than the weight-limited number, routing weights are leaving capacity unused.

Spare headroom >= 0 RPS means modeled demand fits the current weight-limited ceiling.
Spare headroom < 0 RPS means the modeled demand is above the planned ceiling.
N+ reserve spare < 0 RPS means the selected failure reserve does not fit modeled demand.
Weight gap means healthy capacity exists but the current weights prevent the pool from using all of it before one backend reaches the planning utilization.
Serving backends below the listed row count means down, draining, invalid, or unrecognized rows are not included in serving capacity.

A Capacity ok badge does not prove the production service is safe. It only means the entered backend maximums, weights, health flags, growth buffer, and reserve setting fit the model. Verify the row-level Utilization, the charted target line, and current load balancer metrics before using the output for a rollout or incident decision.

Worked Examples:

Three serving app nodes each handle 850 RPS at maximum, each has weight 1, and planning utilization is 70%. With Target demand at 1800 RPS, Weight-limited ceiling is 1785 RPS and Spare headroom is -15 RPS. The summary should report Capacity short, even though the pool is only slightly beyond the planned ceiling.

A mixed pool has app01 at 900 RPS, app02 at 600 RPS, and app03 at 900 RPS, all with weight 1 and planning utilization 70%. At 1800 RPS demand, app02 receives the same one-third share as the larger nodes and becomes the bottleneck. Weight-limited ceiling falls to 1260 RPS, while Gross healthy ceiling is 1680 RPS, so Capacity Guidance should call out a weight bottleneck.

An N+1 check uses three identical healthy backends at 850 RPS, planning utilization 70%, and Target demand of 1300 RPS. The normal Weight-limited ceiling is 1785 RPS, so normal spare is 485 RPS. With Failure reserve set to 1, N+1 reserve ceiling drops to 1190 RPS and N+1 reserve spare becomes -110 RPS, so the right reading is normal fit with failed reserve.

A troubleshooting pass starts with a CSV row such as app03,650,1,maybe. The validation area reports that the health flag is not recognized and treats the backend as down. Change the flag to yes, healthy, up, no, down, disabled, or another accepted value, then recheck Serving backends before using the capacity envelope.

FAQ:

Why is the pool ceiling lower than the sum of backend capacity?

The central ceiling is weight-limited. Each serving backend receives traffic according to its routing weight, and the first backend to reach the selected planning utilization sets Weight-limited ceiling.

What health words can I use in the backend CSV?

Healthy values include yes, y, true, up, healthy, enabled, active, and 1. Down values include no, n, false, down, unhealthy, disabled, drain, draining, and 0.

Should planning utilization be 100%?

Use 100% only when you intentionally want the theoretical maximum. For sustained production planning, a lower value such as 65% to 80% leaves room for latency, request mix changes, retries, and measurement error.

Why does N+ reserve fail when normal capacity passes?

The reserve calculation removes healthy backends and recalculates the remaining weighted pool. N+ reserve short means normal demand fits, but the selected failure case leaves too little planned capacity.

What should I do when Review pool inputs appears?

Fix the row named in the message. Max RPS and routing weight must be positive, at least one backend row is required, and unrecognized health text is treated as down until corrected.

Can this replace a load test?

No. It estimates capacity from entered RPS, weights, health, utilization, growth, and reserve settings. Use load tests and production telemetry to confirm backend maximums and real request behavior.

Glossary:

Backend pool: The group of application servers or targets behind the load balancer.
Routing weight: A relative value that controls each serving backend's share of traffic.
Planning utilization: The target percentage of each backend's maximum RPS used for capacity planning.
Weight-limited ceiling: The total pool RPS where the first serving backend reaches planning utilization.
Gross healthy ceiling: The sum of healthy backend maximum RPS values after applying planning utilization.
Spare headroom: The difference between weight-limited ceiling and modeled demand.
N+ reserve: A capacity check that removes one or more healthy backends and tests the remaining pool.
Modeled demand: Target demand after applying the optional growth buffer.

References:

HTTP Load Balancing, NGINX Documentation.
Health checks for Application Load Balancer target groups, AWS Elastic Load Balancing documentation.
Introduction: Site Reliability Engineering, Google SRE Book, 2016.
Handling Overload, Google SRE Book, 2016.