Adding Fallbacks to Circuit Breakers
Learn how to pair a circuit breaker with fallback logic so that when the breaker is open, your service degrades gracefully instead of failing the user request.
Adding Fallbacks to Circuit Breakers is a free Microservices Communication Patterns (Saga, Circuit Breaker) lesson on CoddyKit — lesson 4 of 4. You can read the complete lesson below for free — then practise it hands-on in the browser with a built-in code editor and a 24/7 AI tutor. It is part of the Microservices Communication Patterns (Saga, Circuit Breaker) learning path, one of 4 lessons in the course, and your progress syncs across the web and the CoddyKit app.
Why Fallbacks Matter
A circuit breaker protects your service by failing fast when a dependency is down. But failing fast still means the user gets an error unless you provide a fallback.
A fallback is the plan B that runs when the breaker is open.
The Fallback Contract
A fallback should return a sensible default quickly and never call the same failing dependency. It is invoked when:
- The breaker is open, or
- The protected call throws or times out.
A Simple Fallback
Here is the core idea: try the real call, and if it fails, return the fallback value.
def get_price(call_remote):
try:
return call_remote()
except Exception:
return 'fallback: last-known price'
print(get_price(lambda: (_ for _ in ()).throw(Exception('down'))))Fallback: Cached Value
A common strategy is to serve the last successful response from a cache. The user sees slightly stale data instead of an error.
cache = {'price': 42}
def get_with_cache(breaker_open):
if breaker_open:
return cache.get('price', 'unavailable')
return 'fresh value'
print(get_with_cache(True))Fallback: Default Value
When no cache exists, return a safe default: an empty list, a neutral recommendation, or a generic message. The key is that the user experience degrades, not breaks.
def recommendations(breaker_open):
if breaker_open:
return ['Popular item A', 'Popular item B']
return ['Personalized 1', 'Personalized 2']
print(recommendations(True))Fallback: Alternate Service
Sometimes plan B is another provider. If the primary payment gateway's breaker is open, route to a secondary gateway. Each provider has its own breaker.
Wiring Fallbacks in Resilience4j
Most libraries let you attach a fallback declaratively. With Resilience4j you decorate the call with a circuit breaker and supply a recover function that runs on failure or open state.
Keep Fallbacks Fast and Safe
A fallback must not introduce new failure modes:
- No call to the broken dependency.
- No blocking I/O that could also hang.
- Bounded, predictable execution time.
Communicating Degradation
Tell the user (and your dashboards) when degraded data is served. A subtle UI note like 'showing cached results' sets expectations, and a metric on fallback rate reveals dependency health.
fallback_count = 0
def record_fallback():
global fallback_count
fallback_count += 1
return fallback_count
print('Fallbacks served:', record_fallback())When NOT to Fall Back
Some operations have no safe default. You cannot 'fall back' on confirming a payment. In those cases, fail clearly and let the caller retry later rather than fabricate a result.
Testing Fallbacks
Write tests that force the breaker open and assert the fallback runs and returns the expected safe value. Fallbacks that are never tested tend to break silently.
Quick Check
Which of these is a valid requirement for a circuit breaker fallback?
Recap
You learned to add fallbacks to circuit breakers:
- Fallbacks run when the breaker is open or the call fails.
- Common strategies: cached value, safe default, alternate service.
- Keep fallbacks fast, safe, and free of the broken dependency.
- Communicate degradation and test fallbacks explicitly.
Fallbacks turn fast failures into graceful degradation.
Frequently asked questions
Is the “Adding Fallbacks to Circuit Breakers” lesson free?
Yes — the full text of “Adding Fallbacks to Circuit Breakers” is free to read here on the web, and the Microservices Communication Patterns (Saga, Circuit Breaker) course includes 4 lessons in total. To practise it interactively (a built-in code editor and a 24/7 AI tutor) and unlock the rest of the Microservices Communication Patterns (Saga, Circuit Breaker) course, upgrade to CoddyKit PRO.
What will I learn in “Adding Fallbacks to Circuit Breakers”?
Learn how to pair a circuit breaker with fallback logic so that when the breaker is open, your service degrades gracefully instead of failing the user request. You practise Microservices Communication Patterns (Saga, Circuit Breaker) with hands-on code you run directly in the browser, and a 24/7 AI tutor answers your questions as you work through the lesson.
Do I need any experience to start Microservices Communication Patterns (Saga, Circuit Breaker)?
No prior experience is required. Microservices Communication Patterns (Saga, Circuit Breaker) on CoddyKit is structured for beginners through advanced learners; this is — lesson 4 of 4, so you can start here or from the beginning and move at your own pace.
How long does the “Adding Fallbacks to Circuit Breakers” lesson take?
Most CoddyKit lessons take about 5–10 minutes. Each one is bite-sized and interactive, so you make steady progress and pick up exactly where you left off across the web and the app.
Can I write and run code in this Microservices Communication Patterns (Saga, Circuit Breaker) lesson?
Yes. Every Microservices Communication Patterns (Saga, Circuit Breaker) lesson includes a built-in code editor, so you write and run real code right in your browser and get instant AI feedback — no local setup required.
All lessons in this course
- Choosing a Circuit Breaker Library
- Configuring Circuit Breaker Instances
- Integrating into Service Calls
- Adding Fallbacks to Circuit Breakers