Concept notes
Why this decision matters
Circuit Breaker Clinic is focused practice for Circuit breakers, timeouts, retries, fallbacks, and dependency isolation. It explains why each answer is safe, risky, or production-ready.
Outages spread when every caller patiently waits, retries, and shares the same exhausted resources. This clinic asks you to prescribe the resilience treatment before one slow dependency infects the whole request path.
Backend concept notes
Circuit breakers stop a caller from repeatedly waiting on a dependency that is likely unhealthy. They work best with short timeouts, bounded retries, jitter, and safe fallback behavior.
Resilience design is not simply keeping pages green. A fallback must preserve business correctness, and bulkheads should stop one dependency from exhausting shared resources.
Common mistakes
- Using very long timeouts that hold threads and amplify outages.
- Counting expected 4xx validation errors as dependency-health failures.
- Retrying without jitter, budgets, or idempotency.
- Serving stale data for correctness-critical decisions such as inventory or payments.
Review misses from this game
Related Backend Study Lab articles
Use the main site for deeper reading after playing.
Start here
Read deeper
Related Backend Study Lab tools
Use tools from the main site when you want to inspect real inputs.
FAQ
Short answers for how this game fits backend interview and study practice.
Is a circuit breaker the same as a rate limiter?
No. Rate limiters control caller volume or fairness. Circuit breakers protect callers and dependencies when a downstream service appears unhealthy.
Should every dependency have the same fallback?
No. Recommendation data may fall back to cache, but payment or inventory decisions often need conservative failure behavior to preserve correctness.