Skip to content

Redundancy N+1 Check

Resilience audit — instantiates Target-Complete Mapping Design

Removes one witness — or one shared dependency — from a protected target's coverage and rechecks that the target is still reached, proving the redundancy is real rather than nominal.

For targets where losing coverage is unacceptable, having "two sources" on the map is not the same as being resilient. Redundancy N+1 Check verifies that a protected target keeps at least one valid witness after any single witness — or any single shared dependency — is deliberately removed. Its defining move is not to count witnesses but to delete one and re-run coverage: a row that shows two sources but collapses to zero when their common vendor, data center, team, or model is knocked out was never redundant at all. The check exists to convert nominal cardinality into tested independence.

Example

A payments platform promises that every currency corridor can settle even if one processor fails. On paper the EUR corridor looks safe — two independent processors are listed. The N+1 check removes Processor A and re-runs: EUR still settles through Processor B, so far so good. Then it removes a shared dependency rather than a witness — the single sanctions-screening vendor both processors call before releasing funds — and EUR coverage drops to zero. The two "independent" witnesses were independent only downstream; upstream they funneled through one screening provider, a hidden single point of failure the two-source row concealed. The outcome is a concrete choice: procure a second screening vendor, or record the correlated risk explicitly instead of pretending the corridor is redundant.

How it works

What distinguishes this audit is adversarial single-removal against the dependency chain, not the witness list. For each protected target it enumerates the witnesses and their dependency chains (read from the cross-source dependency map), removes one element — a witness on one pass, a shared dependency on the next — and recomputes coverage. A target that drops to zero valid witnesses fails N+1. Common-mode dependencies are the real quarry: the nominal two-source rows that survive removing either witness but collapse when the resource they secretly share is removed.

Tuning parameters

  • Redundancy depth (N) — N+1 vs N+2: how many simultaneous removals coverage must survive. Higher depth is more resilient and more expensive to provision.
  • Independence threshold — how much shared dependency is tolerated before two witnesses are counted as one. Tighten it and more rows fail as illusory redundancy.
  • Removal scope — witness-only removal vs witness-and-dependency removal. The latter finds the common-mode failures the former cannot.
  • Protected-target selection — which targets are consequential enough to earn the check, versus those where a single witness is acceptable.
  • Injection realism — desk analysis of the dependency map vs an actual live failover exercise that pulls a real component.

When it helps, and when it misleads

Its strength is turning nominal redundancy into tested resilience: it catches the shared-dependency trap that a witness count is structurally blind to, and it forces "illusory redundancy" out of the coverage map. Its failure mode is that it is only as good as the dependency map — an unmapped shared resource passes the check while the live system stays fragile — and it removes one element at a time, so genuinely correlated multi-failures can still slip through. The classic misuse is running it to rubber-stamp a two-source row without ever removing the shared dependency, which is the theater version of the audit. The discipline that guards against it is to remove dependencies, not just witnesses, and to keep the dependency map current, because the point of failure that matters is the one nobody drew.[1]

How it implements the components

Redundancy N+1 Check realizes the resilience-strengthening slice of the archetype — only the components an independence audit can fill:

  • redundancy_requirement — it enforces the strengthened contract that a protected target retains ≥1 valid witness after any single removal.
  • cross_source_dependency_map — it reads and stress-tests this map, using it to find the common-mode dependencies that make two witnesses effectively one.

It does not size whether a surviving witness can bear the load (that's Source Capacity Load Test) or confirm a witness is valid in the first place (that's Witness Validation Test); it assumes valid witnesses and tests only their independence.

References

[1] A single point of failure is a component whose failure alone halts the whole system; N+1 designs add a spare so no single failure is fatal. The check's real bite is that two nominally separate witnesses frequently share one hidden single point of failure upstream. ↩