Replica Calculator
Calculate the number of pod replicas needed to serve a target request rate, with an availability buffer for rolling updates and node failures.
Inputs
Total requests per second the deployment must handle.
Sustainable requests per second a single pod can serve.
Extra capacity to tolerate rolling updates and node failures without degrading service.
Recommended Replicas
32pods
Base Replicas (No Buffer)
25pods
Extra Replicas for Availability
7pods
Effective Capacity
6,400req/s
Step by step
Base replicas = ceil(total RPS ÷ RPS per pod)
ceil(5000 ÷ 200)
= 25
With availability factor
ceil(25 × 1.25)
= 32
How it works
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
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.