Server
Circuit breaker
Circuit breaker is a guard that stops calling a failing dependency for a short period and returns an error straight away. It saves your threads from waiting on something that is already broken.
How it is measured
A breaker keeps a rolling count of failures and timeouts for one dependency. When the failure rate crosses a threshold, say 50 percent over 20 calls, it opens and refuses calls for a cool-off, often 30 seconds. It then allows a probe call and closes again if the probe succeeds.
You observe it as a state per dependency: closed, open or half-open, plus the count of calls it rejected. Log every state change with a timestamp, because the open period is the part users felt.
Worked example
A checkout calls a tax-rate API that normally answers in 120 ms. The API starts hanging for 10 seconds. Without a breaker, 40 PHP workers are held waiting inside a minute and the whole shop stops responding, including pages that never touch tax.
With a breaker, the 21st failure inside 30 seconds opens it. Checkout falls back to a cached rate in 3 ms, 39 workers stay free, and the half-open probe at 30 seconds closes the breaker once the API recovers.
How it differs
A circuit breaker stops traffic to a dependency that is failing. Backpressure slows callers because your own server is full. The breaker excludes retries to a dead service. Backpressure excludes the idea that the problem is downstream. One protects you from them, the other protects you from your callers.
Common errors
Setting the failure threshold so low a single blip trips it. Opening the breaker with no fallback, so the user just sees a different error. Sharing one breaker across unrelated endpoints. Never testing the half-open path. Leaving the cool-off long after the dependency recovered.
In practice
Pick the one third-party call whose slowness could freeze the app, such as payments, tax, shipping or search, and wrap it with a short timeout plus a breaker and a cached fallback. Alert when a breaker opens for more than a few minutes.