Implementing a Circuit Breaker Mechanism for Backend API Calls

This article explains a practical circuit‑breaker design for backend services, detailing detection logic, algorithm thresholds, time‑window statistics, recovery duration, manual overrides, a global switch, and how to monitor the breaker’s current state using Redis.

Wukong Talks Architecture
Wukong Talks Architecture
Wukong Talks Architecture
Implementing a Circuit Breaker Mechanism for Backend API Calls
Reading Index 1. Circuit‑breaker detection mechanism 2. Circuit‑breaker algorithm 3. Failure‑rate time window 4. Circuit‑breaker duration 5. Manual circuit‑breaker 6. Global detection switch 7. Viewing current breaker status 8. Optimization points and pitfalls

Project requires a circuit‑breaker to protect third‑party API calls from excessive pressure.

0x01. Circuit‑breaker Detection Mechanism

(1) After a request reaches the backend, first check whether the circuit‑breaker switch is on.

(2) If the switch is on, the request is rejected.

(3) If the switch is off, evaluate whether the statistical time window is full.

(4) If the window is not full, increment the request count in the Redis bucket.

(5) If the response contains an error, increment the failure count; otherwise, increment the success count.

(6) When the window is full, decide whether to trigger the circuit‑breaker.

0x02. Circuit‑breaker Algorithm

Necessary conditions:

(1) Total requests > threshold X.

(2) Failure rate > threshold Y.

Total requests are read from the Redis request bucket.

Failure rate = failures ÷ requests × 100%.

When both conditions are met, the API is considered unstable and the circuit‑breaker is activated.

0x03. Failure‑rate Time Window

(1) Each request checks whether the time window (e.g., 5 minutes) is full; if full, the window resets and counters are cleared.

(2) The start time of the first window defaults to the current time.

0x04. Circuit‑breaker Duration

(1) When a problem occurs, all request paths can be cut off; a default recovery time of 1 minute is assumed, adjustable per environment.

(2) Recovery time can be dynamically increased if the network remains poor, allowing the breaker to stay open longer.

0x05. Manual Circuit‑breaker

Sometimes a rapid cut‑off is needed, e.g., when a surge of recharge requests leads to many refunds; manually breaking the package‑retrieval API prevents further recharges.

0x06. Global Detection Switch

A master switch enables or disables the entire circuit‑breaker detection; turning it off stops all breaker checks.

0x07. Viewing Current Breaker Status

To verify that the breaker works, monitor the following parameters:

Wukong Architecture

Follow me for daily incremental improvements!

Additional 111 books are available as gifts.

Original Source

Signed-in readers can open the original source through BestHub's protected redirect.

Sign in to view source
Republication Notice

This article has been distilled and summarized from source material, then republished for learning and reference. If you believe it infringes your rights, please contactadmin@besthub.devand we will review it promptly.

APIrate limitingResiliencecircuit breakerfailure rate
Wukong Talks Architecture
Written by

Wukong Talks Architecture

Explaining distributed systems and architecture through stories. Author of the "JVM Performance Tuning in Practice" column, open-source author of "Spring Cloud in Practice PassJava", and independently developed a PMP practice quiz mini-program.

0 followers
Reader feedback

How this landed with the community

Sign in to like

Rate this article

Was this worth your time?

Sign in to rate
Discussion

0 Comments

Thoughtful readers leave field notes, pushback, and hard-won operational detail here.