# Active Redundancy

**In short:** Active redundancy keeps spare components running alongside the working ones, all processing the same inputs. A spare can take over within milliseconds. This gives the fastest recovery, but it costs the most.

## Explanation

Active redundancy is also called a hot spare setup. It is a way to recover quickly when a component fails. (See Redundant Spare and Fault Recovery Tactic for the wider family.)

**How it works.** The group of components that protects a function is called a protection group. It holds the active components plus the spares. In active redundancy, every member of the group receives and processes the same inputs in parallel.

**Why recovery is fast.** The spare holds the same state as the active component. So it can take over from a failed component in milliseconds. A hot spare is active and connected inside the working system. Even so, switching does not guarantee uninterrupted service.

**What it needs.** Replicated components must be checked for faults. One way is voting (see Voting). A voter compares the results of the replicas. If they differ, it reports a fault. Teams must also build the failover machinery. This includes the logic that promotes a spare and the safeguards against split-brain, where two nodes both believe they are in charge.

**Compared with other spare types.**

- Hot spare (active redundancy): all members process input. Recovery takes milliseconds.
- Warm spare (passive redundancy): only active members process input. Spares get state updates that are only loosely synchronized. Recovery takes seconds.
- Cold spare: the spare stays out of service until a failure. It then needs a power-on reset. Recovery takes minutes, so cold spares suit high-availability systems poorly.

**Automation.** Active redundancy automates fault detection, isolation and reconfiguration. It is common in space, aircraft and missile systems.

## Example

An online payment service runs two identical servers. Both receive every payment request and process it. Only one server's answer is used. The other keeps the same state. If the first server fails, the second takes over within milliseconds. Customers notice little or nothing.

## Trade-offs

- **Cost.** A hot spare is the most expensive option. A mirroring hot spare roughly doubles resource cost.
- **Complexity.** More redundancy raises availability, but it also raises cost and complexity. The team must build, tune and regularly exercise the failover machinery.
- **Standing cost for speed.** Warmer standby recovers faster but costs more all the time. If availability needs are modest, a warm spare may be enough.
- **No guarantee.** Switching over does not promise uninterrupted service.

Active and spare nodes process the same input; a voter compares results and detects faults.

```mermaid
flowchart LR
  In[Identical input] --> A[Active node]
  In --> S[Spare node]
  A --> V{Voter / failure detection}
  S --> V
  V --> Out[Output]
```

## Checks

- The document states which spare type (hot, warm or cold) protects each critical component.
- Where hot spares are used, the document explains how failures are detected, for example by voting.
- The document describes the failover logic and split-brain prevention, and says how they are exercised.
- The extra cost and complexity of hot spares is justified by the recovery time the system needs.

## Related

- [Redundant Spare](https://arc.fuet.ch/concepts/tactics/redundant-spare.md)
- [Fault Recovery Tactic](https://arc.fuet.ch/concepts/tactics/availability-tactics-fault-recovery.md)
- [Voting](https://arc.fuet.ch/concepts/tactics/voting.md)
- [Availability](https://arc.fuet.ch/concepts/quality-attributes/availability.md)
- [Availability Tactic](https://arc.fuet.ch/concepts/tactics/availability-tactics.md)
- [Quantifying Recovery and Availability Trade-offs](https://arc.fuet.ch/concepts/quality-attributes/quantifying-recovery-and-availability-trade-offs.md)
- [Tactic Trade-off Balancing](https://arc.fuet.ch/concepts/tactics/tactic-trade-off-balancing.md)
- [Fault Tolerance](https://arc.fuet.ch/concepts/quality-attributes/fault-tolerance.md)

## Sources

- [3.4 Design Concepts to Support Availability | Making Design Decisions | InformIT](https://www.informit.com/articles/article.aspx?p=3197432&seqNum=4) — informit.com, accessed 2026-11-08
- [Standby/Failover | arc42 Quality Model](https://quality.arc42.org/approaches/standby-failover) — quality.arc42.org, accessed 2026-11-09
- [Hot spare - Wikipedia](https://en.wikipedia.org/wiki/Hot_spare) — en.wikipedia.org, accessed 2026-11-09
- [Active redundancy - Wikipedia](https://en.wikipedia.org/wiki/Active_redundancy) — en.wikipedia.org, accessed 2026-11-09