Fail-Fast vs Fail-Safe
Whether a component should stop immediately on detecting a problem, or continue in a degraded but safe mode — a choice that depends entirely on which outcome is worse.
Fail-fast stops at the first sign of trouble: reject the request, crash the process, refuse to start with invalid configuration. Its virtue is that problems surface immediately, close to their cause, before bad state propagates. Its cost is availability.
Fail-safe continues in a reduced mode: serve stale data, skip enrichment, use a default. Its virtue is availability; its cost is that a problem can persist unnoticed and, if the degraded mode is subtly wrong, propagate incorrect results.
The choice follows from what the failure would cost. A configuration parser should fail fast — a service running with half-parsed configuration is worse than one that will not start. A recommendation engine should fail safe. A payment authoriser should fail fast. A logging pipeline should fail safe, and must never be able to fail the request it is logging.
The related and frequently mishandled pair is fail-open versus fail-closed for security controls. An authorisation service that is unreachable should fail closed, denying access; a rate limiter that is unreachable usually should fail open, allowing traffic, since denying everything is a worse outcome than briefly not enforcing a limit. Deciding this per control, in advance, is the work.