Circuit Breaker Laravel Package

Product Decisions This Supports

• Build vs. buy vs. vendor for resilience primitives. A circuit breaker is a small, well-understood state machine (closed → open → half-open). This package is a candidate for "vendor it" rather than "buy," which is a real product decision when the alternative is a managed resilience layer or a bespoke internal utility.
• Scoping third-party dependency protection. It supports the decision to treat external calls (payments, SMS/email, shipping quotes, tax/geo lookup, search, partner webhooks) as failure domains rather than as code paths that simply "work or throw." This is the feature-level decision behind graceful degradation.
• Reliability roadmap placement. Deciding whether circuit breaking is a Q1 hardening item or a "someday" ticket. The package makes the cost of the first increment low enough that it can be scoped as a spike rather than a project.
• Fallback and degradation UX decisions. Once you can detect an open circuit, you can decide per feature what users see: cached results, a stripped-down flow, a queue-and-retry, or an explicit "temporarily unavailable" state. Those are product calls, not engineering ones, and a breaker makes them triggerable.
• Incident-cost tradeoffs. Protecting a non-critical integration from cascading into checkout latency is a cost/availability decision that this pattern makes concrete and testable.
• Where NOT to invest. Low adoption signals (17 stars, last release 2017, low evaluation score) support a deliberate decision to not standardize on this package across the org, and instead keep it as a reference implementation or a short-term bridge.

When to Consider This Package

Adopt only under a narrow set of conditions:

• You are on an older PHP/Laravel stack (roughly PHP 7.x / Laravel 5.x era) and need a drop-in breaker without pulling in a larger resilience dependency.
• Your breaker needs are simple: a per-integration threshold, a cooldown window, and a half-open probe. No adaptive rates, no per-tenant circuits, no sophisticated fallback policy engine.
• You are willing to own the code. MIT license makes forking and vendoring legally clean, so treat this as source material rather than a dependency you expect upstream to maintain. Budget an owner and a small test suite.
• You need a shared state store. Confirm early whether state can live in Redis (or your cache) so that it is shared across PHP-FPM workers, queue workers, and horizontally scaled instances. A per-process breaker in a multi-worker deployment gives you false confidence — this is the single most important thing to verify before committing.
• You can validate it in a time-boxed spike against your actual HTTP client and error taxonomy (timeouts vs. 4xx vs. 5xx — a breaker should generally not trip on client errors or validation failures).

Look elsewhere, or build in-house, when:

• You are on modern Laravel/PHP 8.1+. An unmaintained 2017-era package is a compatibility and security-review liability with little upside; the pattern is ~200 lines and easier to own than to justify a stale dependency.
• You need observability integration (metrics, structured logs, alerting on state transitions) — you will likely be writing this yourself anyway.
• You need adaptive or sophisticated behavior: dynamic thresholds, per-tenant or per-route circuits, bulkheads, retry budgets, or coordinated fallbacks. That argues for a maintained resilience library or a homegrown service layer.
• Your dependency policy requires active maintenance, security advisories, or a supported-version guarantee. This package will not meet it.
• The client stack matters. If your calls go through a modern HTTP client with its own middleware/retry story, wiring your own middleware may be cleaner than adapting an older API.

How to Pitch It (Stakeholders)

For executives: We're evaluating a small, MIT-licensed PHP library that implements the circuit breaker pattern — the mechanism that stops our app from hammering a failing third-party service and dragging down checkout or onboarding with it. It's cheap to trial and the license lets us own the code. The honest caveat: it hasn't been updated since 2017 and has minimal community traction, so the recommendation is to use it as a reference implementation or a short-term bridge on legacy services, not as a long-term dependency. The pattern is straightforward enough that if we adopt it, we should own it.

For engineering: Treat this as vendored source, not a supported dependency. Two things gate adoption: (1) breaker state must be shared across workers and instances — verify Redis-backed state before writing any code; (2) it must be tested against our actual failure modes, so client errors don't trip the circuit and timeouts do. If either fails, a ~200-line in-house implementation with the same interface is the better outcome. Either way, we get a fast, low-risk first step toward protecting our critical third-party integrations, and a clear decision point on whether resilience primitives are something we buy, borrow, or own.