การเพิ่มกลไกสำรองให้ Circuit Breaker

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.

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.

Here is the core idea: try the real call, and if it fails, return the fallback value.

A common strategy is to serve the last successful response from a cache. The user sees slightly stale data instead of an error.

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.

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.

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.

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.

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.

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.

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.

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.