AT7 — Automation/Control: A circuit breaker automates the detection and isolation of dependency failures. Without it, engineers must manually identify failing dependencies, manually configure load balancers to route around them, and manually restore traffic after recovery. The circuit breaker does all three automatically: it detects failure by counting errors, isolates by rejecting requests without manual intervention, and restores by probing the dependency and closing when recovery is confirmed. The control cost is configuration complexity: the failure threshold, reset timeout, and HALF-OPEN probe count all require tuning to the specific characteristics of the dependency. A threshold that is too low trips on transient failures (network blips, slow requests during garbage collection pauses). A threshold that is too high allows too many requests to reach a failing dependency before tripping. Correct calibration requires production traffic data and ongoing adjustment as dependencies’ failure patterns change.
AT1 — Consistency/Availability: When a circuit breaker is OPEN, all requests to the protected dependency return an error immediately. From the caller’s perspective, the dependency is unavailable — not slow, but instantly failing. This is an improvement over waiting for timeouts (better for the caller’s latency), but it means the caller must handle an increased error rate during the open window. If the caller cannot degrade gracefully — if it requires a successful response from the dependency to serve its own request — the open circuit breaker surfaces the downstream failure to the end user rather than hiding it. The circuit breaker trades partial failure (some requests to the dependency fail) for complete isolation (all requests to the dependency fail while the circuit is open). This is correct for system stability but requires callers to implement graceful degradation (Chapter 21) to avoid propagating the error to users.