FM2 — Cascading Failures Prevented by Circuit Breaker: A circuit breaker directly addresses FM2. Without circuit breakers, a slow or failing dependency causes callers to wait for responses that never arrive. Caller threads are held while waiting. Each held thread represents a slot in the caller’s thread pool. When all thread pool slots are held by waiting requests, the caller cannot process new requests — it effectively becomes as unavailable as the dependency. Callers of the caller experience the same problem. The failure cascades upward through the dependency tree. With circuit breakers at each service boundary, a failing dependency trips its circuit breaker after N failures, causing subsequent requests to be rejected immediately rather than waiting. Thread pools are not exhausted. Callers of callers continue to function normally (with degraded or missing features from the unavailable dependency, but not complete failure).
FM11 — Observability Blindness When Circuit Opens Silently: A circuit breaker that opens but does not alert is worse than no circuit breaker — it hides the failure while making the system’s behaviour invisible. From the user’s perspective, a feature stops working. From the engineer’s perspective, there are no errors in the upstream service (it is returning fast errors, not slow errors) and no alerts. The root cause — a failing downstream dependency — is invisible unless the circuit breaker state is exported as a metric and monitored. Every circuit breaker state transition (OPEN, HALF-OPEN, CLOSED) must be emitted as a metric and trigger an alert on OPEN. The circuit breaker state itself — the name of the dependency and the current state of its breaker — must be visible in the service’s health dashboard. A circuit breaker that opens without notification is an observability failure.