Stackbook Logo
resilienceestablished · low operational burden

N+1 Redundancy

Also known as: spare-capacity, n-plus-m-redundancy

Intent

Provision at least one more unit of capacity than the load requires so a single failure does not cause overload.

Problem

A fleet sized exactly for peak load loses capacity when one node fails, and the survivors then receive more traffic, which can push them over and trigger a cascading failure. Cheap redundancy is needed without doubling infrastructure.

Forces

  • •Capacity costs money
  • •Failures are routine at scale
  • •Load redistributes to survivors
  • •Correlated failures exceed a single spare

Solution

Overview

N+1 redundancy means having N units that carry the load plus one spare. It is the baseline availability design for fleets, power supplies, and storage arrays.

How it works

Work out how many units peak load needs when each runs at a safe utilization, then add one.

peak load            9000 rps
safe per node        1500 rps (70 percent of max)
N = 9000 / 1500      = 6
deploy N+1           = 7 nodes
after one failure    6 nodes at 1500 rps each

For zones the math changes. With three zones and one allowed to fail, each zone must be able to take half of the load, so total capacity is 150 percent of peak. With more zones the overhead drops, for example four zones need about 133 percent.

Pitfalls

  • Teams measure utilization with all units healthy, so alerts miss the fact that one failure would breach limits. Alert on N-1 utilization.
  • Placing the spare in the same rack or zone defeats the purpose.
  • During a deployment one unit is already out of rotation, so a rolling update plus one failure needs N+2.
  • Load balancers may not redistribute evenly and overload a few survivors.
  • Growth silently consumes the spare, so review capacity regularly.

Key takeaways

  • Size N from peak load at a safe utilization.
  • Spread units across independent failure domains.
  • Monitor headroom as if one unit were already lost.
  • Use N+2 when deployments or correlated failures overlap.

✓ When to Use

  • •Load-balanced stateless tiers
  • •Storage and power or cooling systems
  • •Systems that must tolerate rolling maintenance during failures

✗ When Not to Use

  • •Dev and test environments
  • •Workloads where elastic autoscaling can respond in time
  • •Cases where failures are correlated beyond the spare count

Pros

  • +Tolerates a single failure without degradation
  • +Cheaper than full duplication
  • +Simple to reason about

Cons

  • −Constant cost of spare capacity
  • −Does not cover multi-failure events
  • −Spare units must be proven healthy

Cost Profile

Infrastructure

Medium, one extra unit or zone share

Operational

Low, capacity reviews

Cognitive

Low, simple concept

Failure Modes

  • Two simultaneous failures exceed the spare

  • Spare capacity quietly consumed by growth

  • Spare nodes share a failure domain with the primaries

Real-World Examples

Alternatives

    Related Patterns

    • static-stability
    • shuffle-sharding

    Competency Domains

    reliability opseconomics evolution