Why Circuit Breaking and Degradation Are Essential for High‑Availability Microservices

Why Circuit Breaking and Degradation Matter

In complex microservice environments, each service handles a specific business function, which improves development speed but can reduce overall system availability when failures propagate across services. Service Level Agreements (SLAs) expressed as “Nines” quantify availability, and strategies such as circuit breaking, degradation, rate limiting, and isolation are used to maintain high reliability.

Typical Failure Scenario

A real‑world incident is illustrated where Service B receives a request from upstream Service A, forwards it to downstream Service C, and then returns the result. Monitoring graphs show a sudden traffic drop on day 29, a spike in response latency, and a sharp decrease in throughput, indicating that an upstream instability caused Service B to become blocked and its throughput to collapse.

When a dependent service becomes unstable, response times increase, causing the calling service’s throughput to fall, thread pools to fill, and eventually the service may become unavailable.

What Circuit Breaking and Degradation Actually Do

Circuit breaking acts as a pre‑condition: once a configured threshold is reached, further calls are blocked, similar to a blown fuse. After the circuit opens, degradation logic is executed on the client side, providing a fallback response (e.g., returning null) instead of invoking the unstable remote service.

Degradation strategies must be tailored to the specific business scenario; there is no one‑size‑fits‑all solution.

Popular Degradation Libraries

Three widely used open‑source libraries are compared:

Sentinel (Alibaba)

Hystrix (Netflix)

Resilience4j (Java)

Sentinel is praised for its readable code and ability to distinguish business exceptions from those that should trigger a circuit break, allowing developers to apply different fallback strategies.

Isolation Strategies

Thread‑pool isolation provides strong resource separation but adds context‑switch overhead. Semaphore isolation limits the number of concurrent calls with a lightweight counter, reducing server load but not supporting asynchronous execution.

Sentinel Degradation Architecture

Sentinel’s degradation mechanism consists of four parts: rule definition, data statistics, rule verification, and degradation execution.

Rule Definition

Each rule includes a degradation strategy (grade) and parameters such as statIntervalMs (statistics window), timeWindow (circuit‑open duration), and minRequestAmount (minimum request count before triggering). The three strategies are illustrated in the accompanying diagram.

Data Statistics

When a request enters SphU.entry("customResource"), Sentinel creates an Entry object and a chain of slots. The StatisticSlot records runtime metrics, while other slots (FlowSlot, AuthoritySlot, DegradeSlot, SystemSlot) enforce flow control, blacklist/whitelist, degradation, and system‑level limits respectively.

The statistics are aggregated using classes such as ArrayMetric, BucketLeapArray, MetricBucket, and WindowWrap. The StatisticSlot triggers subsequent slots; if no BlockException is thrown, the request is considered successful and counters are updated.

Rule Verification

Verification occurs in the DegradeSlot. The slot retrieves the pre‑loaded CircuitBreaker for the resource, checks the current state, and throws a DegradeException if the circuit is open.

Degradation Execution

Once the circuit is open, the fallback logic defined by the developer is executed. This may simply return a default value (e.g., null) or invoke an alternative code path. Developers must ensure that the fallback does not introduce new failures for downstream callers.

Summary

Sentinel provides a powerful set of features for circuit breaking and degradation. Understanding the degradation strategies, rule parameters, statistics collection, verification logic, and fallback implementation is essential for building resilient microservices. Future articles will explore the sliding‑window statistics in greater depth.