N minus 1 sizing
N minus 1 sizing means that the servers left after one failure can still carry the full load. With 3 servers of 1 vCPU, the 2 that remain serve 3,600 requests/s at 54 percent CPU each. With 2 servers, the last one saturates and p99 passes 3 s.
See it on the board
The same traffic runs on two boards. The simulator measured both when this page was built.
| Measure | Goal | Two small servers | Three small servers behind a balancer |
|---|---|---|---|
| p99 latency | under 250 ms | 3.6 s Fail | 69 ms Pass |
| Availability | at least 95% | 99.885% Pass | 99.944% Pass |
| Error rate | under 5% | 0.1% Pass | 0.056% Pass |
| Monthly cost | 10 USD/mo | 14 USD/mo |
Key numbers
| Number | Value |
|---|---|
| CPU time for one API call | 0.3 ms |
| Mean time between failures, one server | 8,760 h |
| Recovery time after a failure | 30 s |
280 req/s · CPU 70% · mean 22 ms
How it works
Adding servers protects you only if the rest can do the work. Count the load, remove one server, and check what is left. That is N minus 1.
In the mini board the API serves 3,600 requests/s, and each call needs 0.3 ms of CPU. That is about 1.08 vCPU of work. One server of 1 vCPU cannot carry it. Two servers can carry it only while both are up.
So with two small servers, a failure leaves one server with the load of two. Its queue grows, and p99 rises above 3 s. With three small servers, a failure leaves two servers. Each runs at 54 percent CPU, and the service stays inside its limits. One large server is worse: when it fails, nothing is left.
The cost of this safety is idle capacity. With N minus 1 sizing, the servers run at less than full load when all are up. Many teams also plan for the failure of a whole zone, which needs more spare capacity again. Do the sum for the failure you want to survive.
In the levels you size a layout for the load after a failure, then check p99 and availability.