Why does redundant systems fail?

The most common reason redundant systems fails: Confusing redundancy with waste. You will recognize this failure when you resist creating backup systems because they seem inefficient, when you optimize for leanness by eliminating every 'duplicate' capability, or when you centralize all critical functions through a single point because it feels cleaner. The deeper error is evaluating redundancy only during normal conditions, when it does appear wasteful, and ignoring the conditions under which it becomes the difference between survival and collapse. Efficiency and resilience are in tension. Systems optimized purely for efficiency are fragile. The redundancy you resent maintaining during calm periods is the redundancy that saves you during storms.

The fix: Map one critical dependency in your life — a skill, a relationship, a tool, an income source, or an information channel that, if it disappeared tomorrow, would cause serious disruption. Now identify your current redundancy level for that dependency. Do you have zero backup paths (single point of failure), one alternative (basic redundancy), or two or more alternatives (robust redundancy)? For anything at zero, design one concrete backup path you could establish this week. For anything at one, ask whether your backup is truly independent — or whether it shares a failure mode with your primary path. Write down the dependency, its current redundancy level, and your proposed improvement.

The underlying principle is straightforward: Multiple paths between important nodes make a system more robust.