Redundancy is insurance against failure. But how much redundancy is enough? The answer depends on your availability requirements, budget, and failure modes. This section explores common redundancy models and when to use each.

# N+1 Redundancy

Definition: You need N equivalent components to handle the required peak load and deploy one additional component. This tolerates one independent component failure without service degradation only if the failure is detected and isolated, load transfers successfully, and the remaining N components have sufficient capacity.

Pros: Cost-effective (only 25% extra capacity in this example). Handles single failures.

Cons: Second concurrent failure causes degradation. N+1 capacity alone does not protect against a shared failure that removes multiple required units, such as a rack-level power event.

Best for: Non-critical workloads, budget-constrained environments, stateless services where scaling down temporarily is acceptable.

# N+2 Redundancy

Definition: You need N equivalent components to handle the required peak load and deploy two additional components. This can tolerate two independent component failures if they are detected and isolated, load transfers successfully, and the remaining N components have sufficient capacity.

Pros: Tolerates two failures. Good for maintenance (take one offline) + unexpected failure scenario.

Cons: Higher installed capacity (50% above N in this N=4 example); actual cost depends on the complete design.

Best for: Critical services, environments with frequent maintenance, higher availability requirements (99.9%+).

# 2N (Dual Redundancy)

Definition: Deploy twice the required capacity (100% redundancy).

Pros: Extremely high availability. Can lose entire failure domain (rack, AZ) and continue. Allows aggressive maintenance schedules.

Cons: Expensive (100% capacity overhead). Wasteful if failures are rare.

Best for: Mission-critical infrastructure (payment processing, healthcare systems), SLA requirements of 99.99%+, compliance-driven environments.

# Comparison Table

# Active-Active vs Active-Passive

Beyond capacity planning, how redundant components operate matters for performance and failover speed.

Active-Active Architecture

All redundant components actively serve traffic simultaneously. Load is distributed across all instances.

Pros:

• All instances serve normal traffic, but sufficient spare headroom or tested scale-up is still required to absorb a failure
• Instant failover—load balancer stops routing to failed instance
• Horizontal scaling is possible for tiers designed to scale out; shared or stateful bottlenecks can still limit capacity
• Provisioned instances can all serve normal traffic while the design retains failure headroom

Cons:

• More complex—requires load balancing, state management
• Session handling complexity (sticky sessions or shared state)
• Harder to guarantee consistency (if stateful)

Best for: Stateless web services, APIs, microservices, read-heavy databases (read replicas).

Active-Passive Architecture

One component (primary) actively serves traffic. Backup (secondary) is on standby, takes over only when primary fails.

Pros:

• Often a simpler write topology, but replication, monitoring, fencing, and failover coordination are still required
• A single-writer topology avoids concurrent-writer conflicts; consistency and durability guarantees depend on replication and failover configuration
• Easier to reason about

Cons:

• Standby capacity may be underused for normal traffic; a warm standby still replays changes, and a hot standby can serve reads
• Slower failover—must detect failure, promote standby (10s-60s typical)
• Risk of split-brain if both become active
• Does not increase write capacity by default; hot standbys or read replicas can increase read capacity

Best for: Write-heavy databases, stateful services, systems requiring strong consistency, legacy applications not designed for active-active.

Comparison: Active-Active vs Active-Passive

# When to Use Which Model

Stateless services (web, API): Active-active with N+1 or N+2 redundancy. Load balance across instances, auto-scale based on demand.

Databases (write-heavy): Active-passive with N+1 (primary + standby). Promote standby on failure. Consider N+2 for maintenance window + unexpected failure.

Databases (read-heavy): Active-passive primary for writes + active-active read replicas. Writes go to primary, reads distributed across replicas.

Mission-critical infrastructure: 2N redundancy with active-active (if possible) or active-passive (if consistency required). Deploy across multiple failure domains.

# Key Takeaways

• N+1 tolerates one failure (cost-effective), N+2 tolerates two (higher availability), 2N tolerates half fleet (mission-critical)
• Active-active uses all capacity, instant failover, but complex state management
• Active-passive wastes standby capacity, slower failover, and can simplify write coordination, but consistency depends on replication and failover configuration
• Choose model based on: availability SLA, budget, failure frequency, consistency requirements
• Stateless services: active-active. Write-heavy databases: active-passive. Read-heavy: hybrid.