The central problem
Design for a failed component.
Good network reasoning separates the mechanism from the symptom. Start with the boundary, identify the evidence, and test the explanation that accounts for the observation.
Place the risk
Redundancy must cross failure domains.
Two devices do not provide independent availability if they share the same power source, rack, link, zone, or upstream dependency. A single failure domain can remove every supposedly redundant option at once.
Map the dependencies before declaring a design resilient. Then test each domain separately, including the path used to detect failure and the path used to serve traffic.
Build the model
Four useful signals
Redundancy
Provides another path or component.
Health check
Tests whether a path or service is usable.
Failover
Moves work to the surviving option.
Recovery
Restores the preferred arrangement after repair.
Mini investigation
Inspect the evidence
Select the observation and identify the most direct next check.
This observation narrows the mechanism but does not prove every downstream layer.
Compare it with one nearby-layer check.
Knowledge check
Test your model
Answer five questions.