A Circuit Breaker is used whenever a service depends on another component whose failure could otherwise cascade and destabilize the entire system, particularly when that dependency is prone to slowness or intermittent unavailability.
Key Points: • It's especially valuable for calls to external or third-party APIs that the team doesn't control and that may become slow or unresponsive without warning. • It's useful anywhere a synchronous chain of service calls exists, since a hang in one service can otherwise ripple upward and exhaust resources in every caller above it. • It should be applied to any dependency where failing fast with a fallback is better for the user experience than waiting indefinitely for a timeout. • It's less necessary for calls that are already asynchronous and decoupled via a message queue, since those aren't blocking a caller in real time. • It pairs naturally with a fallback method, so instead of just failing, the system can degrade gracefully — e.g., returning cached or default data.
Example: A Product Page calling an external Recommendation API is a prime candidate for a circuit breaker: if that third-party API becomes slow, the breaker trips and the page falls back to showing generic "popular products" instead of hanging or crashing the whole page load.
Interview Tip: A concise interview answer is:
"I'd add a circuit breaker anywhere a synchronous call to another service could hang or fail unpredictably and risk cascading up to the caller — especially calls to external APIs I don't control. It lets the system fail fast with a fallback instead of tying up resources waiting on a dependency that's clearly struggling."