The left panel is what happens when you try to recover from an error using try-catch. The error originates on the call stack. An exception object is allocated on the heap. The catch block checks Redis for the retry count. It increments the circuit breaker. It attempts to roll back the partial database write. It logs the swallowed exception. It pushes a retry message to the dead letter queue. Six memory locations, touched in sequence, each one a place where recovery state can go wrong, become stale, or be forgotten.
The right panel is the let-it-crash alternative. The process fails. It dies. All its state dies with it; nothing to roll back, nothing to clean up, nothing to log. The supervisor notices the process is gone and starts a fresh one. Two memory locations. Two events. The new process starts from a known-good state because it has never seen the bad input that killed its predecessor.
Every catch block is a bet that you can anticipate the failure mode and write correct recovery logic for it. The more catch blocks you write, the more recovery state you scatter across your infrastructure. The let-it-crash model bets that a fresh start from a known-good state is safer than trying to recover from an unknown-bad state. Thirty years of Erlang in telecom systems proved that bet correct.