Bird
Raised Fist0
Microservicessystem_design~3 mins

Why Circuit breaker pattern in Microservices? - Purpose & Use Cases

Choose your learning style10 modes available

Start learning this pattern below

Jump into concepts and practice - no test required

or
Recommended
Test this pattern10 questions across easy, medium, and hard to know if this pattern is strong
The Big Idea

What if your whole system could avoid crashing just by knowing when to stop trying?

The Scenario

Imagine you have a busy restaurant kitchen where chefs keep trying to cook dishes even when the stove is broken. They keep wasting time and ingredients, making the whole kitchen slow and chaotic.

The Problem

Without a way to stop trying when something is clearly broken, the kitchen gets overwhelmed. Chefs keep failing, orders pile up, and customers get frustrated. Similarly, in software, if services keep calling a failing service, it slows down the whole system and causes errors to spread.

The Solution

The circuit breaker pattern acts like a smart kitchen manager who notices the broken stove and tells chefs to stop cooking on it temporarily. This prevents waste and chaos. In software, it stops calls to a failing service, letting it recover and keeping the system stable.

Before vs After
Before
response = callService()
if response fails:
    retry immediately
else:
    process response
After
if circuitBreaker.isClosed():
    response = callService()
    circuitBreaker.recordSuccessOrFailure(response)
else:
    return fallbackResponse()
What It Enables

It enables systems to stay responsive and resilient by preventing cascading failures and allowing quick recovery.

Real Life Example

When a payment service is down, the circuit breaker stops all payment requests temporarily, so the rest of the app keeps working smoothly without waiting or crashing.

Key Takeaways

Manual retries can overload failing services and cause system-wide slowdowns.

Circuit breaker stops calls to failing services to protect the system.

This pattern improves reliability and user experience in distributed systems.

Practice

(1/5)
1. What is the primary purpose of the circuit breaker pattern in microservices?
easy
A. To prevent repeated calls to a failing service and improve system stability
B. To increase the speed of database queries
C. To encrypt communication between services
D. To balance load evenly across servers

Solution

  1. Step 1: Understand the problem circuit breaker solves

    The circuit breaker pattern stops calls to a failing service to avoid cascading failures.
  2. Step 2: Identify the main benefit

    This pattern improves system stability by preventing repeated failures and allowing recovery.
  3. Final Answer:

    To prevent repeated calls to a failing service and improve system stability -> Option A
  4. Quick Check:

    Circuit breaker purpose = prevent repeated failing calls [OK]
Hint: Circuit breaker stops calls to failing services fast [OK]
Common Mistakes:
  • Confusing circuit breaker with load balancing
  • Thinking it speeds up database queries
  • Assuming it encrypts data
2. Which of the following correctly represents the three states of a circuit breaker?
easy
A. START, STOP, PAUSE
B. ACTIVE, INACTIVE, PENDING
C. CLOSED, OPEN, HALF_OPEN
D. ON, OFF, WAIT

Solution

  1. Step 1: Recall circuit breaker states

    The circuit breaker has three states: CLOSED (normal), OPEN (blocking calls), HALF_OPEN (testing recovery).
  2. Step 2: Match states to options

    Only CLOSED, OPEN, HALF_OPEN lists these exact states.
  3. Final Answer:

    CLOSED, OPEN, HALF_OPEN -> Option C
  4. Quick Check:

    States = CLOSED, OPEN, HALF_OPEN [OK]
Hint: Remember states as Closed, Open, Half-Open [OK]
Common Mistakes:
  • Mixing up state names with unrelated terms
  • Using generic terms like ON/OFF
  • Forgetting the HALF_OPEN state
3. Consider this pseudocode for a circuit breaker:
if state == 'OPEN':
  return 'fail fast'
elif state == 'HALF_OPEN':
  if test_call_successful():
    state = 'CLOSED'
  else:
    state = 'OPEN'
else:
  call_service()
What happens when the circuit breaker is in HALF_OPEN state and the test call fails?
medium
A. The state changes to CLOSED and service calls continue
B. The state remains HALF_OPEN and retries immediately
C. The service call is ignored without state change
D. The state changes back to OPEN and calls are blocked

Solution

  1. Step 1: Analyze HALF_OPEN state logic

    In HALF_OPEN, a test call checks if the service recovered. If it fails, the state changes to OPEN.
  2. Step 2: Understand consequence of failure

    Changing to OPEN blocks further calls to prevent overload.
  3. Final Answer:

    The state changes back to OPEN and calls are blocked -> Option D
  4. Quick Check:

    HALF_OPEN fail -> OPEN state [OK]
Hint: Failed test call in HALF_OPEN resets to OPEN [OK]
Common Mistakes:
  • Assuming state changes to CLOSED on failure
  • Thinking retries happen immediately in HALF_OPEN
  • Ignoring state changes on test failure
4. A developer implemented a circuit breaker but notices it never transitions from OPEN to HALF_OPEN. What is the most likely cause?
medium
A. The timeout to switch from OPEN to HALF_OPEN is missing or too long
B. The service calls are always successful
C. The circuit breaker is stuck in CLOSED state
D. The test call in HALF_OPEN always succeeds

Solution

  1. Step 1: Understand OPEN to HALF_OPEN transition

    The circuit breaker moves from OPEN to HALF_OPEN after a timeout period to test recovery.
  2. Step 2: Identify cause of no transition

    If the timeout is missing or set too long, the breaker stays OPEN indefinitely.
  3. Final Answer:

    The timeout to switch from OPEN to HALF_OPEN is missing or too long -> Option A
  4. Quick Check:

    Missing timeout blocks OPEN -> HALF_OPEN transition [OK]
Hint: Check timeout settings for OPEN to HALF_OPEN switch [OK]
Common Mistakes:
  • Assuming success of service calls affects OPEN state
  • Confusing CLOSED and OPEN states
  • Ignoring timeout mechanism
5. You design a microservice system with a circuit breaker protecting a payment service. The circuit breaker trips (opens) after 5 failures within 1 minute and stays open for 2 minutes before trying again. What is the main tradeoff of setting the open duration too long?
hard
A. Long open duration improves user experience by retrying quickly
B. Long open duration reduces load on failing service but increases request failures for users
C. Long open duration causes the circuit breaker to never open
D. Long open duration increases the number of successful calls

Solution

  1. Step 1: Understand open duration effect

    A long open duration blocks calls longer, reducing load on the failing service.
  2. Step 2: Identify user impact

    While protecting the service, users experience more failures because calls are blocked longer.
  3. Final Answer:

    Long open duration reduces load on failing service but increases request failures for users -> Option B
  4. Quick Check:

    Long open = less load, more user failures [OK]
Hint: Long open = safer service, worse user experience [OK]
Common Mistakes:
  • Thinking long open improves user experience
  • Assuming circuit breaker never opens with long duration
  • Believing long open increases successful calls