Design the object model and core APIs for a circuit breaker: a reusable component that wraps a call to an unreliable remote dependency, watches how those calls fare, and short-circuits future calls when the dependency looks unhealthy so the caller fails fast instead of piling onto a dying service.

Operating context. The breaker sits in-process in front of one remote dependency (say, a payment gateway). A caller hands the breaker a unit of work and the breaker either runs it or rejects it outright. It runs three states. In CLOSED it lets calls through and records each outcome; when failures over a recent window cross a threshold it trips to OPEN. In OPEN it rejects calls immediately (optionally returning a fallback) without touching the dependency; after a cool-down it moves to HALF_OPEN. In HALF_OPEN it admits a small number of trial calls: enough consecutive successes close it again, any failure re-opens it. Many caller threads share one breaker instance concurrently, and each protected call also has its own timeout that counts as a failure.

Out of scope. The network transport and (de)serialization of the wrapped call, retry / backoff policy, bulkhead thread-pool isolation, distributed or cross-process breaker state sharing, and the metrics dashboards or alerting backend that consume the exported counters.

What to produce. The class hierarchy (the breaker, its states, the failure-counting window, the policy/config, the outcome and metrics types), the public API each class exposes, and the state-transition rules with their trigger conditions. Be explicit about: how the rolling failure window is measured and reset; how the transition timer to HALF_OPEN is driven by an injected clock rather than wall time; how a per-call timeout is turned into a recorded failure; how a fallback is supplied and invoked on rejection; and how concurrent callers observe and mutate breaker state without races or lost counts.