One slow microservice can make your entire Rails application slow.

We often see this in systems where a Rails application depends on multiple external services.

Payment APIs.
Authentication services.
Inventory systems.
Third-party integrations.

Imagine one service starts responding slowly.

Rails keeps waiting.
Requests start accumulating.
Threads remain occupied.
Retries add even more traffic.

Soon, a problem in one service starts affecting other parts of your application.

This is where the Circuit Breaker pattern helps.

Instead of continuously calling an unhealthy service, the circuit breaker changes its behaviour.

Closed: Requests flow normally.
Open: After repeated failures, requests are stopped temporarily.
Half-open: A limited number of requests are allowed to check whether the service has recovered.

In a Rails application, this can be implemented around external API clients using timeouts, failure thresholds and recovery checks.

But a circuit breaker needs more than just blocking requests.

You also need:
- Sensible request timeouts
- Controlled retries with backoff
- Fallback responses where possible
- Monitoring of circuit state
- A clear recovery strategy

Important learning:
Retries help recover from temporary failures.

Circuit breakers prevent repeated failures from consuming resources and spreading across your application.

Don't let one unhealthy dependency become an application-wide incident.