Separation of concerns divides responsibilities so they can be defined and changed independently. In fault-tolerant software, the key split is between normal processing and recovery after failure. When ordinary objects call one another directly, exception handling becomes interwoven with processing: callers may lose input context, buffer work themselves, coordinate concurrent failures with locks, and arrange retries. Functional behavior and recovery behavior then change together instead of remaining isolated. section 5.1.1
Figure 5.1 Processing logs from the FileWatcher, to the LogProcessor, to the Writer, and to the database
A log-processing pipeline makes the coupling visible: direct calls connect the FileWatcher, LogProcessor, Writer, and database, so an error can propagate back through the call stack and pull recovery concerns into normal processing. section 5.1.1
Actor supervision makes the split explicit. An actor handles its normal messages, while a supervisor wraps its behavior and chooses a recovery action after an exception. The supervisor can restart an actor, replace it with a fresh instance, stop it, or use other routing choices without embedding reconstruction details in the actor’s message-processing logic. While the decision is pending, the failed actor’s mailbox is suspended. section 5.1.2
Figure 5.6 Supervisor wrapping an actor’s behavior and deciding on a recovery action after an exception
The supervisor wrapper shows recovery as a separate control flow around an actor’s behavior: an exception leads to a supervisory decision rather than becoming ordinary message-processing code. section 5.1.2
Keep the separation useful during fault recovery:
- Place actors most likely to fail low in the hierarchy, where more actors can handle or monitor their faults. section 5.1.2
- Keep normal message processing independent from restart, replacement, stopping, and other supervisory decisions. section 5.1.2
- Avoid direct object coupling when it forces callers to own buffering, retry context, locking, and lifecycle reconstruction. section 5.1.1
Recovering a log processor
A FileWatcher sends work through a LogProcessor to a Writer. With direct object calls, a Writer failure can unwind through the chain and force processing code to participate in recovery. With actors, the LogProcessor can retain its message behavior while a supervisor decides whether the faulty actor restarts, is replaced, or is stopped. section 5.1.1 section 5.1.2
