Use a circuit breaker for a failing quote service

A circuit breaker protects the application from repeatedly calling a service that is already failing. It should act on service failures, not on every unsuccessful trade request.

Choose the right signals

A proposed breaker counts timeouts, connection errors and qualifying server failures over a bounded window. Invalid user input, unsupported pairs and ordinary no-route outcomes should not automatically open it. Those responses can mean the provider is functioning correctly.

HTTP status semantics help classify transport outcomes, but your adapter must also interpret application-level errors. For instance, a successful HTTP envelope can still contain a provider failure code.

Use three explicit states

Closed permits normal traffic. Open rejects or skips new quote requests for a defined cooldown. Half-open allows a small number of probes to assess recovery. Choose thresholds from measured behavior and operational objectives, not arbitrary numbers advertised as universal defaults.

Track breakers by relevant scope. An outage on one chain or endpoint should not necessarily disable every provider capability. Conversely, a shared authentication failure can affect all chains under one credential.

Preserve in-flight evidence

Opening a quote breaker must not delete stored transaction hashes or stop independent RPC receipt tracking. Status polling for accepted orders may require a separate budget and recovery path. The interface can stop offering new swaps while still explaining earlier attempts.

Display reduced provider coverage in comparisons. Do not silently label the best remaining result as best across all configured services.

Test recovery with a sequence of failures followed by a successful probe. Verify that many application instances cannot all flood the provider when the cooldown ends. A controlled shared probe policy or jittered recovery schedule prevents the breaker itself from creating the next spike.