Free — no signup required

The N+1 and N/0.7 Rules: Practical Capacity Formulas

2 min read

Beyond the Math: Rules Engineers Actually Use

Erlang C gives you the theoretical foundation. In practice, capacity planning uses two simple rules that encode this math into actionable formulas.

The N+1 Rule (Minimum Redundancy)

For any critical service, you must have at least one more instance than the minimum required to handle load. If you need N instances to serve traffic, deploy N+1. This ensures that if one instance fails (hardware failure, deployment gone wrong, AZ outage), the remaining N instances can still handle the load.

Warning: N+1 is a minimum for fault tolerance, not a capacity planning target. If N instances are already running at 90% utilization, losing one instance and redistributing its load to the remaining N instances will push them to 100%+ — causing an outage during the very failure event you were trying to survive.

The N/0.7 Rule (Utilization Target)

This is the Erlang C insight encoded as a formula. Calculate the number of instances needed to serve your peak load at 70% utilization:

Instances needed = ceil(Peak TPS / (Instance capacity TPS × 0.70))

Then apply N+1 on top of that result for fault tolerance:

Final count = ceil(Peak TPS / (Instance capacity TPS × 0.70)) + 1

For the payment service example:

Peak TPS:          400
Instance capacity: 100 TPS
At 70% util:       100 × 0.70 = 70 TPS effective capacity per instance
Instances needed:  ceil(400 / 70) = ceil(5.71) = 6
Plus N+1:          6 + 1 = 7 instances

Seven instances for 400 TPS when each handles 100 TPS. Intuition says 4. Math says 7. The difference is the margin between a reliable service and a 3 AM incident.

When to Revisit Your Capacity Plan

Capacity planning is not a one-time exercise. Revisit it when:
- Traffic grows by more than 20% from your planning baseline
- A new feature significantly changes the resource profile per request (e.g., adding image processing to a previously text-only API)
- You change instance types or move to a different infrastructure
- Your SLO changes (tighter latency targets require more headroom)
- You observe P99 latency trending upward without a corresponding traffic increase (a sign you are approaching saturation)

This is one of 18 chapters

Every chapter is free — Kubernetes, Terraform, SRE, distributed systems, and more — with fast daily review built in.

Sign up free