# Design Circuit-Breaker-Aware Database Routing Design request routing for one primary database and two secondary replicas, each with an independent circuit breaker. A breaker moves from CLOSED to OPEN after two consecutive failed requests, and a request must fall back to a replica when the primary is not accepting requests. Request outcomes are supplied through per-server result functions. ### Constraints & Assumptions - Success resets the consecutive-failure count for the server that was attempted. - Breaker state is independent per server. - The source does not define replica priority, OPEN-state recovery, or whether one logical request may try more than one replica. ### Clarifying Questions to Ask - How is a replica selected when both are available? - Does OPEN ever transition to HALF_OPEN or CLOSED, and what time or probe rule controls recovery? - What exactly do the injected result functions return or throw, and when is a failure counted? ```hint Isolate server state Model each server's breaker and outcome accounting separately from the policy that selects the next server. ``` ### What a Strong Answer Covers - Per-server consecutive-failure state and the CLOSED-to-OPEN threshold. - Separation of routing policy, injected request execution, and breaker updates. - Explicit fallback, retry, and recovery semantics instead of invented rules. - Concurrency, failure isolation, tests, and observable routing decisions. ### Follow-up Questions 1. How would simultaneous requests avoid racing the failure counter? 2. What safeguards prevent recovery probes from overwhelming a recently failed server?