RELIABILITY · LIVE EXPERIMENT
Circuit breaker: protected vs bypassed
Break a dependency, watch the gate protect it, and decide when traffic can safely return.
Scroll the diagram left or right to inspect every label.
0 requests generated · 0 recovery probes
Your experiment
Compare dependency attempts with the breaker enabled and bypassed. Explain why fast rejection is not a successful response.
- Run the scheduled outage and inspect the state history.
- Pause, change one control, and step forward.
- Compare a second run using the same seeded traffic.
Successes + dependency failures + fast rejections + in-flight requests must equal requests generated.
Decision trace
Model assumptions: one shared breaker, consecutive-failure trip threshold, fixed response time, one half-open probe, and one successful probe to close. No retries or production network calls. Scheduled outage runs from 8s to 30s; changing the error rate switches to manual control. Rejected requests are not successful responses. Pattern reference.
Watch completed failures open the gate
The breaker starts CLOSED and admits generated requests. Consecutive failed responses open it after the configured threshold. OPEN blocks new calls locally while in-flight calls still finish. After cooldown it enters HALF-OPEN and allows one probe; other requests fail fast until that response arrives. A successful probe closes the breaker and a failed probe reopens it. Old in-flight responses are tied to an earlier state epoch and cannot incorrectly change a newer breaker state.
Set load and response behavior
Requests per second controls generated demand. Dependency errors is the seeded failure probability assigned when each request is created. Consecutive failures to open sets the completed-failure streak threshold; a success clears the streak. Cooldown sets time spent OPEN and Response time delays admitted completions. Enable circuit breaker toggles protection; bypass admits requests even during failure. The Healthy preset starts a healthy manual scenario. Outage + recovery schedules failure from second eight through just before thirty, then recovery.
Understand manual changes and history
Break service sets persistent hundred-percent errors and Repair service sets persistent zero errors. Either leaves scheduled mode. Editing Dependency errors also replaces the schedule with a persistent rate; editing other fields retains its current schedule. Play toggles Pause, Step +1s advances one second, Restart resets current settings, and Speed changes the ninety-second viewing pace. Replay recorded history can inspect only recorded time. Resuming or editing from a past point creates a branch and discards the later recorded future.
Reproduce an outage and recovery
Choose Outage + recovery with twelve requests per second, hundred-percent outage errors, threshold three, cooldown six and response time 0.6 seconds. Step past eight seconds and observe that responses must finish before OPEN appears. Continue through thirty seconds: the dependency becomes healthy but the breaker may remain open until cooldown and a successful probe complete. Compare an otherwise identical bypassed run. Protected demand is redistributed among blocked, failed, successful and still-pending requests; it is not simply erased.
Check conservation and limitations
At every state generated equals successful plus failed plus blocked plus pending. Attempted equals successful plus failed plus pending. A blocked request has no dependency effect in this fixture, whereas an admitted call is not cancelled when the gate opens. There is no queue, retry, timeout, rolling error-rate window, fallback result or external service. Failure probability is synthetic and sampled with a repeatable generator; this is not measured ADK performance. A repaired service can still have earlier failed calls finishing because their outcome was fixed at admission.