Backend Architecture
Circuit breakers: free-recall review
Retrieval beats re-reading. For each prompt, say or write a full answer from memory before you open the model answer — the effort of recall is what makes the material stick.
Reconstruct the unit’s spine — why slow beats dead, the three-state machine, the trip condition, bulkheads, the timeout-and-fallback pair, and the fleet-scale failure modes — without looking back at the lessons.
- 01Why is a slow dependency more dangerous than a fully dead one, and what is a circuit breaker's core job?
- 02Describe the three states of a circuit breaker and the four transitions between them.
- 03What is the trip condition, and why is a minimum-volume floor essential?
- 04Why isn't a breaker enough on its own, what does a bulkhead add, and what is the thread-pool-vs-semaphore tradeoff?
- 05Why is a timeout the trigger and a fallback the answer, and why should graceful degradation be rare?
- 06How do breakers, retries, and shedding change when you scale from one process to a fleet?
If you could reconstruct each answer from memory, you hold the unit’s spine: slow beats dead because callers block and starve a shared pool; the three-state machine (closed counts, open rejects, half-open probes) fast-fails a sick dependency; the trip condition is a failure rate over a sliding window gated by a minimum-volume floor with slow counted as failure; a bulkhead isolates the budget per dependency where the reactive breaker cannot; a timeout makes a hang countable and a fallback decides what to return when open; and at fleet scale the dangers are per-instance state, retry amplification, herding probes, and uncoordinated shedding — each needing a fleet-level answer.