Replica Calculator
Determine the number of replicas needed to handle expected traffic and failover.
About Replica Calculator
Sizing replicas purely on throughput (total RPS ÷ RPS per pod) leaves no slack for the moments when full capacity isn't available — during a rolling update a fraction of pods are always being replaced, and node failures can remove capacity unexpectedly. Applying an availability factor on top of the base replica count keeps the service within its SLO even when some replicas are temporarily unavailable.
Formula
replicas = ceil(ceil(totalRPS / rpsPerPod) × availabilityFactor)
- T
- Target total requests per second
- R_p
- Sustainable RPS per pod
- A
- Availability factor (typically 1.2–1.5×)
- R
- Recommended replica count
Worked example
With the default values below, Replica Calculator returns Recommended Replicas of 32. Change any input above and every figure here is recalculated in your browser.
Inputs used
- Target Total RPSaccepts 0–10,000,000 req/s
- 5,000 req/s
- RPS per Podaccepts 0.1–1,000,000 req/s
- 200 req/s
- Availability Factoraccepts 1–3 ×
- 1.25 ×
Results
- Recommended Replicas
- 32 pods
- Base Replicas (No Buffer)
- 25 pods
- Extra Replicas for Availability
- 7 pods
- Effective Capacity
- 6,400 req/s
Step by step
- 1Base replicas = ceil(total RPS ÷ RPS per pod)= 25
- 2With availability factor= 32
Assumptions and limits
- The result is derived only from the 3 inputs listed above. Anything not among them is not part of the calculation.
- In particular, this calculator does not take inflation, tax, fees or charges or compounding frequency into account.
- Figures are rounded for display to whole numbers, so totals built from several rounded parts can differ slightly from the unrounded arithmetic.
How these calculators are built and tested is described on the Methodology page. If a figure looks wrong, please report it.
Frequently Asked Questions
What availability factor should I use?
1.2–1.3× is typical for standard rolling updates with maxUnavailable=25%. Multi-AZ deployments tolerating a full zone outage often need 1.33-1.5× (to survive losing 1 of 3 zones) or higher.
How do I measure RPS per pod?
Load test a single pod (or extrapolate from production per-pod metrics) up to the point where p99 latency starts degrading — use that sustainable point, not the absolute breaking point.
Should this replace HPA, or work alongside it?
Use this as your HPA's minReplicas floor for baseline traffic — HPA should still scale above this dynamically based on real-time metrics as load grows beyond the target RPS.