Lecture
Crash-only software refers to computer programs that handle failures by simply restarting, without attempting complex recovery. Properly written crash-only software components can micro-reboot into a known-good state without user intervention. Because failure handling and normal startup use the same code paths, this can increase the likelihood that bugs in the failure-handling code will be discovered, except in cases where there are residual artifacts, such as data corruption caused by a severe failure, that do not occur during a normal startup.
Crash-only software is an approach in which software systems are designed so that they can only shut down by crashing and then restarting. Unlike traditional applications, which provide procedures for graceful shutdown and recovery, crash-only software assumes that any shutdown is a failure that will be followed by a restart.
Crash-only software also has benefits for end users. All too often, applications do not save their data and settings while running, but only at the end of a session. Word processors, for example, typically save settings on close. A crash-only application is designed to persist any changed user settings shortly after they are changed, so that the persistent state matches the state of the running machine. No matter how the application terminates (whether by a clean shutdown or by a laptop battery suddenly dying), the state is preserved.
Crashing and restarting as the standard operation: The application is designed so that its only way to shut down is to crash. It must be ready to restart at any moment and to recover its state with minimal impact on users.
Idempotent operations: The system's operations must be idempotent, i.e. re-executing them must not produce unexpected results. For example, if the application was suddenly stopped, restarting it should return it to a working state without errors and with the same results as if no failure had occurred.
Minimizing state held in memory: Ideally, the system's state should not reside solely in RAM, so that it is not lost in the event of a crash. State is persisted to external storage (for example, a database or the file system), which makes it possible to restore it quickly on restart.
Component isolation: Each component of the system is designed so that the failure of one component does not affect the others. This is achieved by using a microservice architecture or other distributed architectures, in which the failure of a single component does not bring down the entire system.
Simpler development and debugging: Because the application is designed to crash and restart, there is no need to handle complex shutdown and recovery scenarios. This simplifies the code and makes it more reliable.
Fault tolerance: Crash-only applications are more resilient to errors, since they treat failures as part of normal operation. Instead of trying to prevent a failure, the system simply restarts, which increases its reliability.
Simpler state management: A system built on this principle minimizes the state held in memory and often uses external storage to persist the current state, which simplifies recovery.
Imagine a simple web application with a microservice architecture in which every microservice follows the crash-only principle. For example, the user authentication service might store the user's session in a database. In the event of a failure it will shut down, but on restart it will simply restore its state from the database.
Crash-only software is used in high-load and distributed systems, for example:
Crash-only software is an approach that requires careful preparation and design, but in the end it simplifies maintaining the system, making it more reliable and resilient to errors.
Comments