Broadway Saga Laravel Package

Technical Evaluation

Architecture fit. This package is a Laravel micro-module wrapper around the Broadway saga pattern (broadway/broadway-saga). Broadway is a CQRS/event-sourcing library with a distinct domain model: aggregates, event streams, read model projectors, and sagas as long-running process managers that listen to events and emit commands. That means the package only fits an application that has already committed to Broadway as its event-sourcing backbone, or one willing to adopt it wholesale. It is not a general-purpose workflow/orchestration tool and will not compose with spatie/laravel-event-sourcing, Laravel's native queue batching, or a Temporal/Camunda-style external orchestrator. For the large majority of Laravel codebases the architectural fit is poor — the cost is not the wrapper, it is the paradigm.

Integration feasibility. Mechanically the integration is small: composer require, Laravel package auto-discovery, a service provider binding saga repositories and an event bus into the container, and presumably a config file. The real integration work sits underneath the wrapper. Broadway's saga state repository is Doctrine DBAL-oriented (a per-saga table with a version/lock column for optimistic concurrency), which is an impedance mismatch in an Eloquent-first stack — expect to either register a raw PDO/DBAL connection or write your own SagaStateRepository implementation. There is no evidence of shipped migrations or an Eloquent adapter, so that is likely bespoke work.

Technical risk. High, concentrated in provenance and maintenance rather than in code quality per se. Signals: 0 stars, 0 dependents, a single 2021-09-07 release, and a namespace (micro-module/*) that suggests an internal or experimental module published for convenience. The upstream Broadway project itself has seen little activity, so this layer is a wrapper over a low-velocity dependency. Concrete risks: (1) version constraints almost certainly predate Laravel 10/11 and PHP 8.2+, so service-provider and container-binding compatibility is unverified; (2) transitive Doctrine DBAL drift is a classic breakage vector on a composer update; (3) supply-chain exposure — an unmaintained, near-zero-adoption package from an unfamiliar maintainer is a squatting/abandonment profile, and it should not be installed unread; (4) the interesting behavior (saga lifecycle, compensation, state locking) lives in the upstream dependency, so the wrapper's own quality tells you very little.

Key questions to resolve before any decision.

• Is this a fork of broadway/broadway-saga? At what upstream commit, and has it diverged?
• What exactly does the module add — DI bindings and config only, or behavioral changes to saga dispatch and state handling?
• What are the composer.json constraints for php, illuminate/*, broadway/broadway, and doctrine/dbal?
• Which state repository implementations ship, and is there an Eloquent/query-builder adapter, or must one be written?
• Does it include migrations, a test suite, and CI status? Is the code small enough to audit in an afternoon (likely yes)?
• Are saga timeouts, retries/backoff, and dead-letter handling present, or absent by design?

Integration Approach

Stack fit. Adopt only if the target service is genuinely event-sourced and Broadway is already the chosen backbone; otherwise treat this as a reference implementation to read, not a dependency to install. If the goal is simply "orchestrate a multi-step business process with compensation," a queue-driven state machine (Laravel jobs + an explicit saga_state table + idempotency keys) or an external orchestrator will be cheaper to own and easier to hire for than Broadway.

Migration path. Do not consume it from Packagist as a floating constraint. Fork it into your own VCS, pin the exact upstream commit, and require it via a vcs or path repository. That converts an abandoned dependency into vendored code you control — the only defensible posture for a package with zero dependents and no release in four years. Wrap it behind your own thin interfaces (SagaRunner, SagaStateStore) so a future swap to a hand-rolled or commercial orchestrator is a refactor, not a rewrite.

Compatibility. Budget a compatibility spike before any commitment. Verify against your current PHP and Laravel versions, run the suite on a fresh install, and confirm the DBAL/Doctrine versions resolve alongside whatever else is in the lockfile. Assume Laravel 8/9-era constraints until proven otherwise, and assume the service provider needs patching for modern container and config publishing behavior.

Sequencing.

1. Source audit (hours, not days — the package is small) and dependency-tree inspection.
2. Sandbox spike: one trivial saga — reserve inventory, confirm, compensate on failure — against your real DB and queue.
3. Write an ADR recording the fit decision, the fork-and-pin strategy, and the exit criteria.
4. If approved: fork, pin, add integration tests around saga start/complete/compensate, and a schema-drift test on the state table.
5. Ship the first production saga against a low-blast-radius process with a manual reconciliation runbook, and instrument it before expanding scope.

Operational Impact

Maintenance. You will own this. Assume zero upstream responsiveness: no security patches, no compatibility fixes, no answers to issues. Plan for a named owner, a fork in your org, and a recurring review to re-evaluate against alternatives. The ongoing cost is low in absolute terms (small codebase) but non-zero and permanent.

Support. Effectively none. No community, no dependents to read issues from, no vendor. Institutional knowledge will be entirely internal, which makes the ramp-up and bus-factor problems worse than the code-size suggests.

Scaling. Sagas are stateful by definition: every step writes to a saga state table, and Broadway's optimistic-locking approach means concurrent handling of the same saga instance produces lock conflicts that must be retried, not failed. Under load, watch for hot rows on long-running sagas, table growth without archival, and event-bus throughput becoming the bottleneck before the sagas themselves do. The saga state store is the scaling seam — size and index it deliberately, and decide early whether you need per-saga-instance sharding.

Failure modes. The dangerous ones are silent: a saga stalls because no worker is polling, leaving business process half-completed with no alarm; duplicate event delivery (at-least-once) triggers a duplicate command because idempotency was assumed rather than implemented; a compensation step fails and leaves data inconsistent with no dead-letter path; lock-conflict retries exhaust and drop. Expect to build scheduling, retry/backoff, dead-letter handling, and reconciliation reporting yourself — none of that is a given here. Add explicit stuck-saga alerting on day one.

Ramp-up. Steep relative to ordinary Laravel work. Engineers must internalize aggregates, event streams, eventual consistency, and compensation semantics before they can reason about a failing saga. Realistically weeks of productive-but-slowing effort for a mid-level team, plus ongoing cognitive load for anyone on-call. Weigh that against the alternative of a plain state-machine orchestrator the team already understands.

Recommendation. Do not adopt for production on the strength of this package. Score 0.03, zero dependents, and a 2021 last release make it a reference implementation, not a dependency. If Broadway is already a strategic commitment, fork and pin it deliberately; otherwise implement orchestration with primitives you already operate.