Symfony Circuit Breaker Bundle Laravel Package

Technical Evaluation

Architecture fit. The package is a Symfony bundle (tourze/symfony-circuit-breaker-bundle), not a Laravel package. Laravel and Symfony share PHP, Composer, and PSR interfaces, but they do not share a bootstrapping model: Symfony bundles register through Kernel::bundles() with Extension/CompilerPass wiring and a FrameworkBundle-backed container, while Laravel uses service providers and its own container. A bundle therefore cannot be dropped into a Laravel app — the dependency-injection, config-loading, and service-tagging code paths have no execution entry point. Laravel does consume individual Symfony components (HttpFoundation, Console, Process, etc.), but not symfony/framework-bundle, which a bundle of this kind typically requires.

Integration feasibility. Low to moderate at this version. The viable path is to consume the underlying circuit-breaker logic rather than the bundle, and re-host it in a Laravel service provider. Whether that is even possible is the first thing to determine:

• Is the breaker core published as a separate framework-agnostic package, or is all logic inside the bundle's DI extension?
• What does composer.json require — symfony/framework-bundle, symfony/dependency-injection, symfony/http-kernel? Any of these adds a parallel container and risks version conflicts with Laravel's own pinned Symfony components.
• Where is breaker state stored? Symfony Cache contract, PSR-6/PSR-16, or in-process memory? This single answer determines whether the package is usable at all in PHP-FPM.
• Is it HTTP-client middleware, or a generic callable/annotation wrapper? Only the former maps cleanly onto Laravel's HTTP client.

Technical risk. High. The 0.0.1 release notes contain no feature description, no configuration reference, and no migration or compatibility statement — only a changelog link. There is nothing to validate behaviour against except source. The tourze/* namespace pattern (many small, rapidly versioned bundles) implies churn and a low bus factor. A 0.0.x version permits breaking changes on every patch bump.

Key questions.

1. Is breaker state shared across processes (Redis/Memcached/DB) or per-request? Per-request state makes the breaker decorative in PHP-FPM and queue workers.
2. What is the failure policy when the state backend itself is unavailable — fail-open or fail-closed?
3. What is the half-open probe policy, and is it concurrency-limited (thundering-herd protection)?
4. Does it emit events/metrics/logs on state transitions, and are those PSR-14 events we can bridge to Laravel's event dispatcher?
5. Is the core logic separable from the bundle, or does everything live in DI extension code?
6. PHP and Symfony version constraints, and licence?
7. Is there any documented support commitment, or is this effectively an unmaintained personal package?

Integration Approach

Stack fit. Composer install is frictionless; bootstrap is not. Three options, in descending order of preference:

1. Core-only adoption (recommended, pending Q5). Require only the underlying breaker package, register it in an AppServiceProvider, and expose it via a small facade or a thin wrapper class. Back it with Laravel's cache/Redis so state is shared. This keeps the Symfony container out of the app entirely.
2. HTTP-client middleware wrapper. If the breaker is middleware-shaped, adapt it to Illuminate\Http\Client\PendingRequest::withMiddleware() or Guzzle middleware so protection is applied at the outbound-call boundary with no call-site changes.
3. Full bundle adoption (not recommended). Pulling symfony/framework-bundle into a Laravel application to satisfy one resilience concern is disproportionate and invites dependency-hell with Laravel's own Symfony pins.

Fallback if (1) proves impossible: Laravel-native alternatives — Http::retry() with backoff plus a custom breaker keyed on Redis counters, or a maintained community circuit-breaker package.

Migration path. None required; no prior state. Introduce behind an application-owned interface (CircuitBreakerInterface) so the implementation is swappable, and never reference the vendor namespace directly from domain code.

Compatibility. Must verify before any spike: php constraint, symfony/* constraints, cache contract chosen (PSR-6 vs PSR-16 vs Symfony contracts), and whether any transitive dependency clashes with the Laravel version in use. Assume nothing from a 0.0.1 release.

Sequencing.

1. Source read (30–60 min) — answer the seven questions above; no code.
2. Sandbox spike in a scratch Laravel app, single outbound integration, Redis-backed state.
3. Introduce the wrapper interface and pilot on one non-critical third-party call.
4. Measure: does it open when it should, close when it should, and is behaviour consistent across workers?
5. Decide adopt / fork-and-vendor / build-in-house, and record the decision.

Operational Impact

Maintenance. Pin the exact version ("0.0.1"), not a caret range — 0.0.x permits breaking changes in patch releases. Budget for reading the diff on every bump. Maintain a documented exit ramps: wrapper interface plus, if adoption proceeds past pilot, a vendored fork contingency.

Support. No documentation is signalled by this release; expect to read source and to have no upstream community to lean on. Internal ownership must be explicitly assigned — this cannot be adopted as a "set and forget" dependency.

Scaling. Circuit-breaker correctness is entirely a function of shared state. With in-process state, breakers diverge across PHP-FPM workers, Octane workers, and queue consumers: some workers open, others keep hammering a failing dependency, and the breaker provides false assurance during exactly the incident it was bought for. Shared Redis/Memcached state with atomic increment/TTL semantics is a hard requirement, and that backend becomes a new critical-path dependency.

Failure modes.

• Breaker stuck open after downstream recovery — turns a transient degradation into a self-inflicted outage.
• Thundering herd on half-open — all workers probe simultaneously if the half-open gate is not concurrency-limited.
• State backend outage — the breaker's own dependency fails; behaviour must be an explicit, documented fail-open/fail-closed decision, defaulting to fail-open for non-critical calls.
• Silent operation — with no telemetry on transitions, breaker behaviour is invisible in production and cannot be correlated with incidents.

Ramp-up. Low for a Symfony-comfortable engineer (a day). Moderate for a Laravel-only team, which must reason about Symfony container semantics, cache contracts, and compiler passes purely to evaluate the package — cost that is not repaid if option 3 is avoided.

Recommendation. Do not adopt as a dependency at 0.0.1. Fund a one-day source review to answer whether the breaker core is separable and whether state is shareable; only that review can convert this from a high-risk unknown into a viable build-versus-buy decision.