Concept questionMedium~7 minResilience & Dependency Failures Essentials / 3 of 16

Interview question

How does a circuit breaker protect an API, and what must you decide before using one?

Use a circuit breaker around an unhealthy dependency

Explains closed, open, and half-open behavior, failure classification, recovery probes, and the limits of circuit breakers.

1Say itAnswer out loud first

2CompareCompare with Core answer

3RefineRefine with Stronger and Advanced

TL;DR

While the circuit is closed, calls flow normally and relevant failures are counted. When failures or slow calls cross a threshold, the circuit opens and new calls fail quickly or use a defined fallback instead of waiting on the dependency. After a delay it becomes half-open and allows a small number of probe calls. Successful probes close the circuit; failed probes open it again. The policy must count only failures that indicate dependency health, not caller validation or expected business responses.

Full answer below

Practice focus

Circuit states, failure thresholds, recovery probes, dependency scoping, fallback behavior, and observability.

Answer first

Answer path

Core answer first, then checkpoints toward a stronger answer.

Start
Core answer
Start here. This is the direct spoken answer to practice first.
Why this question matters
A circuit breaker stops repeatedly calling a dependency that is already failing, preserving local capacity and giving the dependency room to recover.
While the circuit is closed, calls flow normally and relevant failures are counted. When failures or slow calls cross a threshold, the circuit opens and new calls fail quickly or use a defined fallback instead of waiting on the dependency. After a delay it becomes half-open and allows a small number of probe calls. Successful probes close the circuit; failed probes open it again. The policy must count only failures that indicate dependency health, not caller validation or expected business responses.
Checkpoint
Stronger answer
Optional upgrade with examples, trade-offs, and sharper phrasing.
I would scope the breaker to the real failure boundary, such as one provider operation or endpoint, rather than one global switch for unrelated calls. The threshold needs enough volume to avoid opening on a single error while still reacting before saturation spreads. Half-open probes must be limited so every application instance does not flood the recovering dependency. Opening the circuit does not create a fallback automatically; the API still needs an honest cached, partial, queued, or unavailable response contract.
Finish
Advanced answer
Optional deeper angle for production judgment and nuance.
In production I would combine the breaker with short timeouts, bounded retries, and concurrency isolation, because it reacts to observed failure rather than preventing every overload. Distributed instances usually keep local breaker state, so dashboards aggregate open state, rejected calls, probe outcomes, dependency latency, and user impact across replicas. I would test low-traffic endpoints, intermittent failures, slow calls, deploy restarts, and recovery flapping. Policy changes are versioned and owned, while emergency controls can disable a dependency path without pretending the circuit alone protects business correctness.

Review signals

Use these to catch weak phrasing, shallow reasoning, and risky claims.

Common mistakesCandidateCommon mistakesMistakes that weaken the answer or signal shallow understanding.Open details

Details

Counting every non-success response as dependency failure.
Using one global breaker for unrelated operations.
Allowing unlimited half-open probes.
Assuming a breaker replaces timeouts or idempotency.
Returning stale fallback data without marking its limits.

Red flagsCandidateRed flagsSignals that an interviewer may treat as risky.Open details

Details

The circuit can open but has no defined user response.
Breaker state and rejection count are invisible.
Low traffic never supplies enough recovery probes.
Every replica probes a recovering provider at full volume.

Follow-up prompts

Quick interviewer prompts inside this drill.

Follow-up questionsCandidateFollow-up questionsLikely next questions after the main answer.Open details

Details

Treat these as the next interviewer turn. Answer one out loud, then save the gap in your practice notes.

What belongs in the failure count?
How would half-open behavior work across many replicas?
When is a circuit breaker unnecessary?
What fallback would the endpoint return?

Continue the section

Next in Resilience & Dependency Failures Essentials: Bulkhead Isolation

Step 4 of 16

Isolate dependency failures with bulkheads and bounded concurrency

Opening drill

Concept questionMedium~7 minResilience & Dependency Failures Essentials / 3 of 16

Interview question

How does a circuit breaker protect an API, and what must you decide before using one?

Use a circuit breaker around an unhealthy dependency

Explains closed, open, and half-open behavior, failure classification, recovery probes, and the limits of circuit breakers.

1Say itAnswer out loud first

2CompareCompare with Core answer

3RefineRefine with Stronger and Advanced

TL;DR

Full answer below

Practice focus

Circuit states, failure thresholds, recovery probes, dependency scoping, fallback behavior, and observability.

Answer first

Answer path

Core answer first, then checkpoints toward a stronger answer.

Start
Core answer
Start here. This is the direct spoken answer to practice first.
Why this question matters
A circuit breaker stops repeatedly calling a dependency that is already failing, preserving local capacity and giving the dependency room to recover.
While the circuit is closed, calls flow normally and relevant failures are counted. When failures or slow calls cross a threshold, the circuit opens and new calls fail quickly or use a defined fallback instead of waiting on the dependency. After a delay it becomes half-open and allows a small number of probe calls. Successful probes close the circuit; failed probes open it again. The policy must count only failures that indicate dependency health, not caller validation or expected business responses.
Checkpoint
Stronger answer
Optional upgrade with examples, trade-offs, and sharper phrasing.
I would scope the breaker to the real failure boundary, such as one provider operation or endpoint, rather than one global switch for unrelated calls. The threshold needs enough volume to avoid opening on a single error while still reacting before saturation spreads. Half-open probes must be limited so every application instance does not flood the recovering dependency. Opening the circuit does not create a fallback automatically; the API still needs an honest cached, partial, queued, or unavailable response contract.
Finish
Advanced answer
Optional deeper angle for production judgment and nuance.
In production I would combine the breaker with short timeouts, bounded retries, and concurrency isolation, because it reacts to observed failure rather than preventing every overload. Distributed instances usually keep local breaker state, so dashboards aggregate open state, rejected calls, probe outcomes, dependency latency, and user impact across replicas. I would test low-traffic endpoints, intermittent failures, slow calls, deploy restarts, and recovery flapping. Policy changes are versioned and owned, while emergency controls can disable a dependency path without pretending the circuit alone protects business correctness.

Review signals

Use these to catch weak phrasing, shallow reasoning, and risky claims.

Common mistakesCandidateCommon mistakesMistakes that weaken the answer or signal shallow understanding.Open details

Details

Counting every non-success response as dependency failure.
Using one global breaker for unrelated operations.
Allowing unlimited half-open probes.
Assuming a breaker replaces timeouts or idempotency.
Returning stale fallback data without marking its limits.

Red flagsCandidateRed flagsSignals that an interviewer may treat as risky.Open details

Details

The circuit can open but has no defined user response.
Breaker state and rejection count are invisible.
Low traffic never supplies enough recovery probes.
Every replica probes a recovering provider at full volume.

Follow-up prompts

Quick interviewer prompts inside this drill.

Follow-up questionsCandidateFollow-up questionsLikely next questions after the main answer.Open details

Details

Treat these as the next interviewer turn. Answer one out loud, then save the gap in your practice notes.

What belongs in the failure count?
How would half-open behavior work across many replicas?
When is a circuit breaker unnecessary?
What fallback would the endpoint return?

Continue the section

Next in Resilience & Dependency Failures Essentials: Bulkhead Isolation

Step 4 of 16

Isolate dependency failures with bulkheads and bounded concurrency

How does a circuit breaker protect an API, and what must you decide before using one?

Practice focus

Answer path

Why this question matters

Review signals

Follow-up prompts

Continue the section

How does a circuit breaker protect an API, and what must you decide before using one?

Practice focus

Answer path

Why this question matters

Review signals

Follow-up prompts

Continue the section