Circuit breaker pattern
The circuit breaker pattern is a resilience mechanism that temporarily interrupts or limits operations when specified failure or risk conditions occur, often allowing controlled recovery attempts.
The Art of Code
A circuit breaker is a fault-tolerance pattern that temporarily stops calls to an failing dependency after repeated failures and later permits limited recovery attempts.
- How it is used
- Protects remote calls after repeated failures by short-circuiting requests and enabling fallback or recovery time.
- How deep it goes
- Explains failure detection, open periods, recovery tests, fallbacks, and a configured Resilience4J example without detailing implementation internals.
- Examples
- Uses a randomly failing payment service with a 50% threshold, five-call sliding window, and Resilience4J configuration.
- What you can do after
- Apply it via Resilience4J or Polly to reject calls to repeatedly failing dependencies and provide a fallback.
gRPC Microservices in Go
A circuit breaker is a fault-tolerance pattern that temporarily stops calls to a failing dependency to prevent cascading failures.
- How it is used
- Protects interservice calls from repeated attempts against a failing dependency and helps prevent cascading failures.
- How deep it goes
- Explains state transitions and configuration, then implements a Go breaker around a gRPC call and in a client interceptor.
- Examples
- Uses an order-creation gRPC call, a failure-ratio setting, state-change logging, and a unary client interceptor.
- What you can do after
- Apply it via sony/gobreaker to protect Go gRPC client calls and configure when failures open or reset the circuit.
Read how gRPC Microservices in Go explains circuit breaker pattern →
Google Anthos in Action
A circuit breaker is a distributed-systems fault-isolation mechanism that temporarily stops requests to an failing or unavailable service.
- How it is used
- Uses circuit breaking to preserve microservice availability and functionality during failures, timeouts, overload, or external-service downtime.
- How deep it goes
- Explains the purpose, failure sources, traffic redirection, and service-mesh placement, but does not detail thresholds or state transitions.
- Examples
- Uses an Istio Ingress request to Service A, two Pods, an unreachable Pod, and alternate-service traffic redirection.
- What you can do after
- Operate circuit breaking through Anthos Service Mesh to isolate failing service paths and limit user-visible disruption.
Read how Google Anthos in Action explains circuit breaker pattern →
Python Concurrency with asyncio
A circuit breaker pattern is a fault-tolerance pattern that stops sending requests to a failing or slow service and resumes requests after a configured reset condition.
- How it is used
- Protects backend-for-frontend services from repeated delays and failures in downstream microservices.
- How deep it goes
- Explains closed, open, and half-open states, then implements a simplified asynchronous breaker with configurable thresholds and timing.
- Examples
- Demonstrates slow cart calls, an inventory callback, repeated breaker requests, and a reset after five seconds.
- What you can do after
- Build it from scratch with asyncio, configure failure and reset thresholds, and apply it to asynchronous service requests.
Read how Python Concurrency with asyncio explains circuit breaker pattern →
Bootstrapping Microservices, Second Edition: With Docker, Kubernetes, GitHub Actions, and Terraform
A circuit breaker is a resilience pattern that stops requests to a failing upstream service and resumes them after checking that the service has recovered.
- How it is used
- Protects microservices by stopping calls to failing upstream services and failing new requests immediately.
- How deep it goes
- Explains On and Off states, recovery checks, and configurable delays, but stops short of implementation details.
- Examples
- Uses a failed HTTP request to a particular resource, immediate subsequent failures, and a delayed upstream recovery check.
- What you can do after
- Evaluate/understand when state-based fast failure can protect a service from a failing upstream dependency.
Secure APIs
A circuit breaker pattern prevents repeated calls to an unhealthy dependency and returns a controlled result when that dependency fails or responds unexpectedly.
- How it is used
- Protects applications that consume internal services or third-party APIs from dependency failures and malformed responses.
- How deep it goes
- Defines proxy-based health monitoring and controlled errors, but does not detail circuit states or implementation code.
- Examples
- Uses unavailable or malformed third-party API responses and an outbound proxy that returns a useful error.
- What you can do after
- Apply it by monitoring dependencies, returning controlled errors, degrading gracefully, and validating consumed responses.
Related concepts
- open stateuses · An open state is a circuit-breaker state in which calls to a failing dependency are rejected or fail immediately without being attempted.
- half-open stateuses · A half-open state is a circuit-breaker state that permits a limited number of requests to test whether a previously failing dependency has recovered.
- cascading failureaddresses · A cascading failure is a chain reaction in which the failure or degradation of one component propagates through dependencies and causes further failures or instability.
- closed statehas part · The closed state is a circuit-breaker state in which requests pass normally to a dependency considered healthy.
These guides are generated from the text of Manning books by Manning's knowledge graph and link to the sections they draw on. The full books are available on liveBook and at manning.com.