Circuit Breaker Pattern Interview Questions

False. In the circuit breaker pattern's Open state, the breaker blocks requests from reaching the downstream service and fails them immediately. Requests are forwarded normally only in the Closed state, while the Half-Open state lets a limited number of trial requests through to check whether the downstream service has recovered.

The delay gives the failing downstream service time to recover before the circuit breaker sends any trial requests, reducing the risk of hammering an already-overloaded service and causing further failures.

A circuit breaker typically has three states. In the Closed state, requests pass through to the downstream service normally and failures are counted. When failures exceed a configured threshold, the circuit trips to the Open state, where all requests are blocked immediately without calling the downstream service. After a cooldown period elapses, the circuit transitions to the Half-Open state, in which a small number of trial requests are permitted to probe whether the downstream service has recovered.

The half-open state allows a small number of trial requests to pass through to the downstream service after a cooldown period. If those requests succeed, the circuit closes and normal traffic resumes; if they fail, the circuit reopens. This lets the system test recovery without flooding a still-unhealthy service.

The main purpose is to stop sending requests to service B once failures or slow responses exceed a threshold, so that service A fails fast instead of holding threads while it waits on a degraded downstream. This keeps A's resources free and prevents the failure from cascading upstream.

The three states are Closed, Open, and Half-Open. In the Closed state, requests pass through to the downstream service normally and failures are counted. When failures exceed a configured threshold, the breaker transitions to Open: requests are blocked immediately and a fallback or error is returned without calling the downstream. After a cooldown period elapses, the breaker moves to Half-Open, where a limited number of trial requests are allowed through to probe whether the downstream has recovered. If those succeed, the breaker returns to Closed; if they fail, it reverts to Open.

The HALF_OPEN state allows a limited number of probe requests to pass through to the downstream service to test whether it has recovered. If the probes succeed, the circuit closes and normal traffic resumes; if they fail, the circuit re-opens.

It transitions to Half-Open. In Half-Open a limited number of trial requests are permitted through to the downstream service to probe whether it has recovered. If those trial requests succeed, the circuit moves back to Closed (normal operation). If they fail, the circuit re-opens.

True. In the circuit breaker pattern, the Half-Open state sends a limited number of probe requests to the downstream service. Successful probes return the circuit to Closed, while failed probes send it back to Open, so the breaker tests recovery before resuming full traffic.

The circuit breaker pattern prevents cascading failures in distributed systems by stopping calls to a failing or unresponsive downstream service. When failures exceed a threshold the circuit opens, so requests fail fast instead of piling up and consuming resources (threads, connections, memory) on the caller. After a timeout the circuit enters a Half-Open state to probe whether the downstream has recovered, which protects the downstream (less load during failure) and the upstream callers (freed resources, fast failure).

After the 5th consecutive failure the failure threshold is reached and the circuit transitions from Closed to Open. The 6th request arrives 2 seconds later, well within the 30-second recovery timeout, so it is short-circuited and fails fast without calling the downstream service. The circuit stays Open until 30 seconds have elapsed, at which point it moves to Half-Open and allows up to 3 trial requests.

1. Closed: requests flow through to the downstream service normally; when the count or rate of failures exceeds a configured threshold, the breaker trips to Open. 2) Open: requests are immediately rejected (fail fast) without calling the downstream service; after a configured timeout/cooldown elapses, the breaker transitions to Half-Open. 3) Half-Open: a limited number of trial requests are allowed through to probe the downstream service; if they succeed the breaker returns to Closed, if they fail it goes back to Open.

Add a circuit breaker that trips open after a failure threshold and fails fast until the dependency recovers. It detects a run of failures, short-circuits subsequent calls instead of letting them stack up on a dead dependency, then probes for recovery via a half-open state — directly stopping the thread exhaustion. Raising timeouts or adding retries or instances only feeds the cascade.

A circuit breaker wraps calls to a downstream dependency and trips open after a threshold of failures, so subsequent calls fail fast instead of waiting on a doomed request. This prevents a cascading failure: without it, a slow or down dependency would tie up threads and connections in the caller, exhaust its resources, and propagate the outage upstream. After a cooldown the breaker moves to half-open and lets a probe request through; if it succeeds the breaker closes and normal traffic resumes, otherwise it re-opens.

Use one breaker per dependency, keyed by name, so a failing currency API does not trip the fraud or ledger breakers. Closed: calls pass through and outcomes are recorded in a sliding window of the last 100 calls; exceptions and timeouts both count as failures. Open: trip when the failure rate in the window exceeds 50% and the window holds at least 20 calls. While open, calls fail fast to a fallback (a cached exchange rate, a 'service unavailable' response for fraud checks, or a durable retry queue for ledger writes) for a 30 s cooldown. Half-Open: after the cooldown, admit exactly one probe request at a time while all other calls still fail fast; after 2 consecutive successful probes, transition to Closed and clear the sliding window; any failed probe reopens the circuit and restarts the cooldown. Sharing: keep breaker state in process memory per instance. A shared store such as Redis adds a network hop to every call and would let one shared breaker flip all instances at once. The trade-off is that instances can disagree about a dependency's health, but each one trips and probes on its own evidence, so recovery is staggered and the probe load on a recovering dependency stays bounded by the instance count. Publish state-change events to metrics for dashboards and alerting, but never use that pipeline for control-flow decisions.

To allow a limited number of probe (trial) requests through to the downstream service to test whether it has recovered. If the probes succeed, the breaker closes; if they fail, it reopens.

State machine: the breaker starts Closed, where calls pass through and a sliding window (count-based or time-based) records successes and failures. When the failure rate or consecutive failures exceed a threshold (for example 50% of the last 100 calls, once a minimum sample size is reached), it trips to Open. In Open, calls fail fast with a CircuitOpenError and no network call is made. After a cooldown (waitDurationInOpenState) it moves to Half-Open, where a bounded number of probe calls (for example 1 to 3) are allowed. If all probes succeed it returns to Closed and resets counters; if any probe fails it returns to Open and restarts the cooldown.

Configuration: failureThreshold (count or percentage), minimumNumberOfCalls (samples before the threshold is evaluated), waitDurationInOpenState (cooldown), permittedNumberOfCallsInHalfOpenState (probe count), and callTimeout (a slow call counts as a failure, preventing thread starvation).

Concurrency: in Java, hold the state in an AtomicReference with CAS-based transitions and use LongAdder for counters. In Go, either use a single goroutine that owns state and receives commands over channels, or use sync/atomic CAS on the state plus a mutex guarding multi-field updates. The key invariant is that Half-Open admits exactly one (or a bounded number of) probes: an atomic permit counter is decremented via CAS, so only the winners proceed and the rest fail fast.

Observability: expose a gauge for the current state, counters for total calls, successes, failures and rejected calls, and a histogram of call latency (Prometheus-style). Log every state transition at INFO with a timestamp, and provide a /healthz or /circuitbreaker endpoint reporting current state, recent failure rate and time since the last transition.

Three statements are correct: the client generates a unique key per logical operation and resends the same key on retries, the server persists the key with the operation's result and replays the stored result on a repeat, and idempotency keys are most valuable for non-idempotent verbs like POST. Generating a fresh key per retry defeats the mechanism, and TCP guarantees reliable bytes, not application-level exactly-once.

Three patterns directly address the cascade: a circuit breaker that opens on the inventory service's error rate or latency and fast-fails instead of waiting, a request timeout so threads are released when inventory is slow, and a bulkhead — a separate bounded thread pool for inventory calls — so an inventory slowdown can't exhaust checkout's whole pool. Merging the services into one process undoes the decomposition, and adding replicas just reproduces the pile-up.

False. A circuit breaker is self-healing. After the open timeout elapses it transitions to half-open and lets a limited number of trial requests through. If those succeed it closes and resumes normal traffic; if they fail it re-opens and waits again. This automatic probing lets the system recover without human intervention.

The circuit breaker is OPEN after the 5th call. The failure rate is only evaluated once the window holds at least 5 recorded calls, which first happens at call 5. At that point the window holds 4 failures and 1 success, a failure rate of 4/5 = 80%, which exceeds the 60% threshold, so the breaker transitions from CLOSED to OPEN. Earlier calls did not trigger evaluation because the minimum of 5 calls had not been reached.

In a circuit breaker implementation such as Resilience4j, the choice of sliding-window strategy affects both memory footprint and how failure rates are computed. Fill in the two blanks: a count-based sliding window stores the most recent N individual call outcomes in a fixed-size ring buffer, while a time-based sliding window divides the time range into N fixed-duration buckets and stores only aggregated counts (successes, failures, slow calls) per bucket.

Our circuit breaker is an embeddable library that wraps each downstream call in a decorator, with one breaker instance per dependency and independent configuration. State machine: three states. CLOSED: calls pass through and outcomes are recorded. OPEN: calls are short-circuited immediately with no network I/O and a typed exception is thrown. HALF_OPEN: a bounded number of trial calls are permitted to probe recovery. Transitions: CLOSED→OPEN when the failure rate over the sliding window exceeds the threshold (only once the minimum call count is met); OPEN→HALF_OPEN after the wait duration elapses; HALF_OPEN→CLOSED when the trial success threshold is met; HALF_OPEN→OPEN when a trial fails or the trial failure rate exceeds its own threshold. Configuration knobs (per dependency): failure rate threshold (e.g., 50%), minimum number of calls before evaluation, slow-call duration threshold (slow calls count as failures), sliding window type and size, open-state wait duration, permitted calls in HALF_OPEN, and HALF_OPEN success/failure thresholds. Sliding window: for high-throughput services, a count-based ring buffer (e.g., last 100 calls) gives predictable O(N) memory and a stable sample. For bursty or low-volume traffic, a time-based window (e.g., 60 one-second buckets) captures temporal failure patterns and ages out stale data during idle periods. The minimum-calls setting prevents tripping on a tiny sample. Concurrency: in CLOSED, all calls proceed and outcomes are recorded via a lock-free ring buffer or a short lock. In OPEN, calls fail fast. In HALF_OPEN, an atomic counter or semaphore caps in-flight probes at the permitted number; if 3 probes are allowed and 3 are in flight, the 4th concurrent request is rejected rather than forwarded, preventing a thundering herd when the breaker moves to HALF_OPEN. Observability: every state transition emits a structured event (timestamp, dependency, old/new state, triggering metric) to the event bus. Counters for rejected calls, failures, slow calls, and time-in-state are exported to Prometheus/Micrometer with a per-dependency label. A per-dependency dashboard shows current state, failure rate, time-in-state, and recent transitions. An admin endpoint lets operators force a state during incidents. Fallback: rejected calls return a fallback (cached value, default, or queued retry) or throw a typed exception distinct from downstream errors, so callers can degrade gracefully.

A single shared circuit breaker across several independent dependencies suffers from both failure dilution and failure contamination. Dilution happens when successes from healthy services keep the aggregate failure rate under the trip threshold, hiding a failed dependency. Contamination happens when the breaker trips and blocks calls to healthy services too. Per-dependency breakers avoid both.

Goals & when to split. The pains are concrete: coupled deploys, no fault isolation, and an inability to scale checkout independently of browsing (which is ~50× the traffic). Those justify splitting. But microservices aren't free — they trade in-process calls and ACID transactions for network hops, partial failure, and distributed-transaction headaches. So I split deliberately, by business value, not everywhere at once.

Service boundaries. I decompose by bounded context / business capability: catalog, cart, orders, payments, inventory, shipping. Each is high-cohesion and owns its domain logic and its data. I avoid the anti-pattern of slicing along database tables into chatty anaemic services — boundaries follow how the business reasons about the domain, so services stay loosely coupled.

Database decomposition. Each service gets its own datastore (database-per-service) — this is what actually breaks the shared-DB scaling ceiling and SPOF. Services no longer cross-join each other's tables; instead they expose APIs and emit events. The orders service stores the product id (and denormalises the few fields it needs) and fetches the rest from the catalog API, or subscribes to catalog change events. What we give up is the convenient cross-table join and strong cross-entity consistency — replaced by API calls and eventual consistency.

Communication & gateway. An API gateway fronts everything: it authenticates, routes to the right service, rate-limits, and can fan out/aggregate. Between services I pick per interaction: synchronous REST/gRPC for a read I need right now (get product), asynchronous events for 'order placed' / 'inventory changed' so producers don't block on consumers. Every synchronous call is wrapped with timeouts, retries (idempotent), and a circuit breaker so a slow dependency fails fast instead of hanging the caller.

Cross-service correctness (place order). Placing an order spans orders + inventory + payments — three databases, so no single ACID transaction. I use a saga: a sequence of local transactions with compensating actions. Orchestrated, an order orchestrator does: reserve inventory → charge payment → confirm order; if payment fails after the reservation, it fires the compensation release inventory. The order sits in a PENDING state until the saga completes, and the user sees pending → confirmed (or failed). This is eventually consistent but never permanently leaks reserved stock.

Migration & new failure modes. No big-bang. I use the strangler-fig pattern: keep the monolith running behind the gateway, peel out one service plus its data at a time, route that capability's traffic to the new service (feature-flagged), dual-write / shadow-read to validate, then cut over and delete the monolith's copy. New failure modes — partial failure (one service down), cascading failure (a slow dependency dragging callers down), and added latency from hops — are contained with circuit breakers, bulkheads (isolate resource pools per dependency), idempotent retries with backoff, and distributed tracing so a request can be followed across services.