Graceful Degradation: Implementing Circuit Breakers in Laravel

Previously in this course, we explored advanced logging patterns to gain visibility into our system's health. In this lesson, we shift from observation to action, focusing on Resilience and Architecture. When a mission-critical external service—like a payment gateway or a third-party analytics API—starts timing out, your entire application shouldn't follow it into the abyss. Graceful degradation is our strategy for keeping the core of our SaaS platform alive, even when its limbs are failing.

Understanding the Failure Cascade

In a distributed architecture, synchronous calls to external services are a primary source of instability. If a service is slow, your PHP worker threads hang, waiting for a response. Eventually, you run out of worker processes, your queues back up, and the entire system enters a death spiral.

Graceful degradation is the practice of designing your system to provide a "good enough" experience when a primary feature is unavailable. This requires two distinct patterns:

1. The Circuit Breaker: An automated switch that stops requests to a failing service.
2. The Fallback: A pre-defined response or cached state that replaces the live data.

Implementing a Circuit Breaker

We use the Circuit Breaker pattern to detect failures and prevent further requests to a service that is clearly struggling. Think of it like an electrical breaker: if the current (request rate) is too high or the resistance (error rate) is too dangerous, it "trips" to prevent a fire.

We can implement this using Laravel’s cache layer to track state.

PHP
namespace App\Services\Resilience;

use Illuminate\Support\Facades\Cache;

class CircuitBreaker
{
    protected string $key;

    public function __construct(string $serviceName)
    {
        $this->key = "circuit_breaker:{$serviceName}";
    }

    public function isAvailable(): bool
    {
        return Cache::get($this->key, 'closed') !== 'open';
    }

    public function recordFailure(): void
    {
        $failures = Cache::increment("{$this->key}:failures");
        
        if ($failures >= 5) {
            Cache::put($this->key, 'open', now()->addMinutes(2));
        }
    }

    public function recordSuccess(): void
    {
        Cache::forget("{$this->key}:failures");
        Cache::put($this->key, 'closed');
    }
}

Providing Fallback Responses

A circuit breaker is useless if you don't have a plan for when it trips. When your service layer detects an "open" circuit, it must immediately return a fallback.

In our SaaS project, if the external "Currency Exchange API" goes down, we shouldn't show the user a 500 error. Instead, we return the last known exchange rate from our cache or a default base-currency value.

PHP
public function getExchangeRate(string $currency): float
{
    $breaker = new CircuitBreaker('currency_api');

    if (! $breaker->isAvailable()) {
        return Cache::get("fallback:exchange_rate:{$currency}", 1.0);
    }

    try {
        $rate = $this->client->fetchRate($currency);
        $breaker->recordSuccess();
        Cache::put("fallback:exchange_rate:{$currency}", $rate, now()->addDay());
        return $rate;
    } catch (\Exception $e) {
        $breaker->recordFailure();
        return Cache::get("fallback:exchange_rate:{$currency}", 1.0);
    }
}

Hands-on Exercise

1. Identify a dependency: Look at your current SaaS codebase—find an external API call (e.g., Stripe, SendGrid, or an internal microservice).
2. Implement the Breaker: Create a CircuitBreaker service similar to the one above.
3. Define the Fallback: Update the service responsible for that API call to check the breaker status. If the breaker is open, return a static value or a cached version of the data.
4. Test it: Manually force a failure (e.g., change the API endpoint to a non-existent one) and verify that your application remains responsive rather than hanging.

Common Pitfalls

• Over-sensitivity: Setting your failure threshold too low means the circuit trips during minor network blips. Use a sliding window or a higher threshold to avoid "flapping."
• Silent Failures: Always log when a circuit opens. If your app is "functioning" but providing stale data, you need to know immediately so your team can intervene.
• Ignoring the "Half-Open" State: A production-grade breaker usually has a "half-open" state where it allows a single trial request after a timeout to see if the service has recovered. If you don't implement this, the circuit will stay "open" forever unless manually reset.

Recap

Graceful degradation is a cornerstone of Reliability. By utilizing circuit breakers, we prevent local failures from becoming system-wide outages. By providing strategic fallbacks, we maintain user trust even when third-party dependencies fail. This approach ensures your architecture remains resilient, shifting the focus from "preventing all errors" to "managing failures gracefully."

Up next: We will dive into Custom Middleware Development to intercept requests at the edge and apply these resilience patterns globally across your routes.