What if your system could protect itself from crashing when one part fails?
Why Circuit breaker pattern in HLD? - Purpose & Use Cases
Start learning this pattern below
Jump into concepts and practice - no test required
Imagine you have a busy restaurant kitchen where orders keep coming in nonstop. If one station breaks down, the whole kitchen slows or stops, causing delays and unhappy customers.
Without a way to detect and isolate the broken station, the kitchen staff wastes time trying to fix it while orders pile up. This causes long waits and sometimes the entire kitchen shuts down.
The circuit breaker pattern acts like a smart kitchen manager who notices when a station is failing and temporarily stops sending orders there. This prevents the whole kitchen from getting overwhelmed and allows time to fix the problem.
callService(); // keep calling even if failingif (circuitBreaker.isClosed()) { callService(); } else { fallback(); }
This pattern enables systems to stay responsive and recover gracefully even when parts fail.
In online shopping, if the payment service is down, the circuit breaker stops sending payment requests and shows a friendly message instead of freezing the whole checkout process.
Manual retries can overload failing services and cause system-wide issues.
Circuit breaker detects failures and stops calls to protect the system.
It helps maintain system stability and improves user experience during outages.
Practice
circuit breaker pattern in system design?Solution
Step 1: Understand the circuit breaker pattern role
The circuit breaker pattern is designed to stop sending requests to a service that is failing repeatedly to avoid wasting resources and cascading failures.Step 2: Identify the main benefit
By preventing repeated calls to a failing service, it helps maintain overall system stability and improves user experience by failing fast.Final Answer:
To prevent repeated calls to a failing service and improve system stability -> Option AQuick Check:
Circuit breaker purpose = prevent repeated failing calls [OK]
- Confusing circuit breaker with caching
- Thinking it increases request volume
- Mixing it up with encryption or session management
open state in a circuit breaker?Solution
Step 1: Recall the circuit breaker states
The circuit breaker has three states: closed (normal operation), open (blocking requests), and half-open (testing requests).Step 2: Define the open state behavior
In the open state, the circuit breaker blocks all requests to the failing service to prevent further failures.Final Answer:
The circuit breaker blocks all requests to the failing service -> Option DQuick Check:
Open state = block requests [OK]
- Confusing open with closed or half-open states
- Thinking open state allows requests
- Assuming counters reset in open state
if failure_count > threshold:
state = 'open'
if state == 'open':
return 'fail fast'
else:
call_service()What will happen if
failure_count exceeds the threshold?Solution
Step 1: Analyze the condition for failure count
If failure_count is greater than threshold, the state is set to 'open'.Step 2: Check behavior when state is 'open'
When state is 'open', the code returns 'fail fast' and does not call the service.Final Answer:
The circuit breaker will return 'fail fast' without calling the service -> Option CQuick Check:
Failure count > threshold = fail fast [OK]
- Assuming service call still happens
- Confusing open with half-open state
- Thinking failure count resets automatically
open state and never transitions to half-open. What is the most likely cause?Solution
Step 1: Understand state transitions in circuit breaker
The circuit breaker moves from open to half-open after a timeout period to test if the service has recovered.Step 2: Identify cause of stuck open state
If the timeout is missing or set too long, the circuit breaker will never try half-open state and remain open indefinitely.Final Answer:
The timeout to reset the circuit breaker is missing or too long -> Option AQuick Check:
Missing timeout causes stuck open state [OK]
- Confusing failure threshold with timeout
- Assuming service health affects state directly
- Ignoring the role of failure counting
Solution
Step 1: Understand intermittent failure impact
Intermittent failures mean the service sometimes works and sometimes fails, so quick detection and retry is important.Step 2: Choose configuration for balance
A low failure threshold and short timeout allow the circuit breaker to quickly block failing calls and retry soon, improving fault tolerance and availability.Final Answer:
Set a low failure threshold and short timeout to quickly block and retry the service -> Option BQuick Check:
Low threshold + short timeout balances availability and fault tolerance [OK]
- Setting threshold too high delays failure detection
- Disabling circuit breaker risks cascading failures
- Setting threshold zero blocks all requests unnecessarily
