It is impossible to build a failure-proof software system. A system can run through its lifecycle without failing, but no one can guarantee it will never fail. Writing perfect code does not solve the problem, because even flawless software depends on a physical computer, power, 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, deciding in advance how a system should behave when some of its parts are not working correctly.
This article looks at strategies that help developers deal with failures in their systems. It begins with the reasoning behind an "assume everything breaks" mindset, which prepares teams to expect faults rather than treat them as rare exceptions. It then contrasts avoiding faults with tolerating them, two approaches that serve different purposes in system design.
From there, the discussion turns to practical techniques. Developers need to work out the scope of a failure so they know which parts of a system are affected and which remain healthy. They also need ways to reduce the impact of a failure, so that a problem in one component does not spread across the whole platform.
Finally, the article covers how to handle failures while the system is still running correctly, and how to measure recovery from failures. Tracking how quickly and completely a system recovers gives teams concrete feedback on whether their failure-handling strategies actually work.
Source: ByteByteGo · Summarized by HeadlinesBriefing