Circuit Breaker Pattern Simulator
Simulate the Circuit Breaker pattern with count-based and time-based sliding windows, slow-call rate thresholds, fallback components, and per-component details. Watch requests flow, timeout
Continue with the guided workspace
Use the paired workspace to connect this guide's mental model with live component state, visible signals, and the outcome each step or scenario is meant to prove.
Mental Model
The Circuit Breaker pattern is a critical fault-tolerance pattern used in distributed systems to prevent cascading failures. It wraps network requests to downstream dependencies, failing fast during service degradations to protect upstream worker threads and database pools, and automatically probing for recovery.
The core mental model mirrors an electrical circuit:
- Closed: Normal operation. Requests pass to the downstream service. If failure rates or slow call rates cross thresholds, the breaker trips to Open.
- Open: Fail-fast phase. Requests are immediately blocked and redirected to a Fallback Handler to return cached or default data, bypassing the degraded service.
- Half-Open: Probing phase. After a timeout duration, a limited number of requests are allowed to pass as probes. If they succeed, the breaker returns to Closed. If any fail, it trips back to Open.
For preconfigured stress tests, you can also select the scenario presets directly in the simulator.
Components and Why They Exist
Client App
Represents the application context initiating downstream service calls. Generates request traffic at a configurable rate (RPS) and tracks metrics like success rate and average latency. In the demo, observe request particles start at the Client App and trace successful or fallback outcomes.
Circuit Breakers
Proxies wrapping downstream service calls to isolate faults. Maintain sliding windows of outcomes (failures or slow calls), evaluate trip thresholds, manage breaker states, and fail fast when open. In the demo, watch the sliding window ring buffer show results (green, red, yellow) and the state badge transition between CLOSED, OPEN, and HALF-OPEN.
Downstream Services
Independent microservice dependencies queryable by the client. Process incoming requests, introduce latency or error rates, or experience complete crashes. In the demo, notice that monitor error badges, latency multipliers, and online/offline status indicators.
Fallback Handler
Serves degraded alternative responses when a dependency is unreachable or slow. Intercepts rejected or failed calls and immediately returns a cached or static fallback payload. In the demo, watch rejected traffic particles (purple) redirect to the Fallback Handler and return to the Client App.
Edge Cases and Misconceptions
- Sliding Window Sensitivity: Short sliding windows might trip too quickly on transient spikes, while very long windows delay failure detection. Compare Count-based vs Time-based windows under varying traffic rates.
- Slow Calls and Resource Exhaustion: A service that is slow but not failing can tie up threads and cause cascading failures. The slow call rate threshold trips the circuit before threads exhaust.
- Fallback Health: Fallbacks should be simple and fast. If the fallback handler becomes slow, the client still suffers.
- Probing (Half-Open) Under Load: If the probe traffic allowed in the Half-Open state is too high, it can immediately overload a recovering service, driving the circuit back to the Open state.
Common Questions
Why is a slow call rate threshold necessary in addition to a failure rate threshold?
A slow downstream dependency that doesn't fail immediately blocks worker threads in upstream services. In thread-per-request architectures, this leads to cascading thread pool exhaustion. A slow call rate threshold trips the breaker before threads are exhausted.
How does count-based sliding window compare to time-based sliding window?
A count-based window tracks the last N calls, making it highly sensitive to the exact call count regardless of time. A time-based window tracks calls in the last T seconds, making it appropriate for systems where traffic is bursty and time-sensitive.
What is the role of the Half-Open state?
The Half-Open state acts as a trial phase. It allows a small, controlled number of probe requests to reach the downstream service. If all probes succeed, the circuit breaker closes; if any fail, it trips back to Open, preventing the service from being overwhelmed.
Why must fallback handlers be extremely lightweight?
If the fallback handler executes heavy queries or makes external calls, it can also block worker threads, defeating the purpose of the circuit breaker. Fallbacks should return static defaults, cached values, or fast stub responses.
How do circuit breakers differ from rate limiters?
Rate limiters restrict traffic to protect a service from being overloaded by clients. Circuit breakers restrict traffic to protect the client and downstream dependencies from cascading failures when a dependency is already unhealthy.