It is impossible to build a failure-proof software system. A system may run through its entire lifecycle without failing, but no one can guarantee that it never will. Writing perfect code does not solve the problem, because even flawless software depends on a physical computer, a power supply, working storage and other components. If the machine loses power, the software will fail regardless of its quality.
For this reason, engineers must design for failure. This means deciding in advance how a system should behave when some of its parts are not working correctly. Failure design is a shift in mindset: developers assume that components will break and plan for it, rather than hoping they will not.
The article examines several strategies that help developers deal with failures. It begins with the case for adopting an "assume everything breaks" mindset and then compares avoiding faults with tolerating them. Next, it explains how to determine the scope of a failure, so teams know which parts of a system are affected. It also covers how to reduce the impact of a failure, so that a single problem does not spread across the whole system.
Finally, the piece looks at how to keep the system running correctly while failures are occurring, and how to measure recovery. Together, these approaches give teams a practical framework for building systems that degrade gracefully and recover quickly when things go wrong.
Source: ByteByteGo · Summarized by HeadlinesBriefing