How to Shrink Failure Scope with Circuit Breakers, Degradation, and Link Splitting

Overview

To improve system availability beyond reducing failure frequency and shortening outage duration, the next step is to shrink the failure scope by simplifying service links. This involves four complementary techniques: circuit breaking, degradation, core‑link splitting, and a minimal‑viable‑product (MVP) fallback.

Circuit Breaker

A circuit breaker isolates an overloaded downstream service (e.g., timeout, high error rate, resource exhaustion) by cutting off requests from the upstream service. This prevents fault propagation and keeps the overall system responsive.

Illustrative scenario : an e‑commerce product‑detail page aggregates data from five downstream services. Normal latency:

50 ms (frontend) + 5 × 30 ms (downstreams) = 200 ms per request
1 s / 200 ms × 200 threads = 1000 QPS

If the rating service stalls at 830 ms, the latency becomes:

50 ms + 4 × 30 ms + 830 ms = 1000 ms
1 s / 1000 ms × 200 threads = 200 QPS

Through an automatic circuit‑breaker, the rating service is tripped when its latency or error rate exceeds a threshold, so the request path falls back to a fast stub or cached response and the overall latency stays near the original 200 ms.

Common Java libraries:

Netflix Hystrix Alibaba Sentinel Only weak dependencies should be protected by a circuit breaker. A strong dependency (where upstream service cannot function without the downstream) would render the circuit breaker ineffective.

Strong dependency : Service A depends on Service B; if B fails, A fails.

Weak dependency : Service A depends on Service B; if B fails, A degrades but remains operational.

Degradation

Degradation sacrifices non‑core features during high load or error conditions to preserve core functionality ("saving the king"). The degradation level is controlled via a configuration flag, allowing fine‑grained rollout.

degradation.level = 0  // no degradation
degradation.level = 1  // reject analytics
degradation.level = 2  // reject analytics + promotions
degradation.level = 3  // reject all non‑core features

Example: an e‑commerce merchant‑management system treats login, product, inventory, and order management as core. When overload occurs, features such as analytics, promotions, and financial reports are disabled through the configuration center, keeping the core flow responsive.

Core‑Link Splitting

Core‑link splitting isolates P0‑level services (critical to business continuity) from lower‑priority services at the resource level (separate MySQL, Redis, MQ, Elasticsearch instances). This ensures that failures in non‑core services cannot affect the core path.

Service tier definitions :

P0 : Failure collapses the entire user‑side business (e.g., user aggregation, order service, payment).

P1 : Failure degrades experience but core flows continue (e.g., marketing, rating, CRM).

P2 : Minor impact (e.g., messaging, image search).

P3 : Low‑importance internal tools (e.g., OA, reporting).

Key principles :

Deploy core services and their supporting resources (databases, caches, queues) in isolated environments.

Prevent non‑core services from depending on core services; if needed, duplicate the core codebase for a separate non‑core instance.

Limit core services to roughly 15 % of the total service count to keep the critical path manageable.

Perform a cost‑benefit analysis before undertaking link‑splitting, as it is labor‑intensive.

When implemented, core services can continue operating even if non‑core services experience latency spikes or outages.

MVP Fallback

If circuit breaking, degradation, and link splitting are insufficient, the system can switch to a Minimal Viable Product (MVP) version. The MVP contains only essential user journeys (e.g., login, schedule view, class streaming) and is typically deployed as a single‑service instance isolated from the full micro‑service mesh. This guarantees that critical operations remain available, albeit with a reduced user experience.

Conclusion

The three‑step availability strategy—reducing failure frequency, shortening outage duration, and shrinking failure scope—relies on the concrete techniques described above. Detailed code‑level configurations (e.g., Hystrix command properties, Sentinel rule definitions) are omitted for brevity but should be implemented according to each library’s documentation.