Product Decisions This Supports
- Orchestration vs. choreography for multi-step workflows. A Broadway "saga" is a process manager: it listens to domain events and issues commands to move a long-running business process forward. This package is the Laravel-side glue (service provider/config wiring) for that pattern. It directly informs whether you model workflows as explicit, stateful orchestrators or as emergent chains of event listeners and queued jobs.
- Build vs. buy for process coordination. Every cross-aggregate workflow (order → payment → inventory → fulfillment; signup → verification → provisioning → billing; subscription dunning and cancellation) needs retry, idempotency, compensation, and a durable record of "where are we?". The build-vs-buy question is: hand-rolled status columns and job chains vs. a process-manager abstraction vs. an external workflow engine. This package represents the "thin in-app process manager" option.
- Event-sourcing / CQRS commitment. Adopting this only makes sense as part of a broader Broadway decision — event store, aggregates, projections, read models. It is a forcing function on whether the team is genuinely adopting DDD/CQRS in Laravel or just wants reliable background jobs.
- Roadmap sequencing. If you choose this path, sequencing matters: event store and aggregate boundaries first, sagas second, projections/reporting third. It argues against shipping saga orchestration as an isolated "quick win."
- Use cases where it fits conceptually: payment capture with refund compensation, multi-step onboarding with external provider callbacks, inventory reservation with timeout release, approval chains, order lifecycle with partial-failure handling.
- Risk/ownership decision. With zero stars, zero dependents, and a last release in September 2021, "adopt" realistically means "vendor, fork, and own." That's a resourcing decision, not just a technical one — it becomes a line item in the platform team's maintenance budget.
When to Consider This Package
Consider it when:
- Broadway (or an equivalent event-sourcing stack) is already decided and running in the codebase; this is additive wiring, not a standalone capability.
- You have a genuinely long-running, multi-step process with real compensation logic — not a two-step job chain that Laravel's queue and
Bus::chain() already handle.
- Your team is comfortable with DDD vocabulary (aggregates, commands, events, process managers) and can read Broadway's source when documentation runs out.
- You are willing to pin, vendor, or fork the package and add your own tests; treat it as a reference implementation to learn the pattern from rather than a maintained dependency.
- You need the orchestration state to be inspectable and replayable — a queryable record of which step a business process is in — and you want that inside your Laravel app rather than in a separate service.
Look elsewhere when:
- The workflow is short-lived or linear. Laravel jobs,
Bus::chain(), retryUntil, and failed-job handling cover it with far less ceremony.
- You are not doing event sourcing. Introducing a saga framework without an event store and aggregates buys you vocabulary without benefits, plus a steep onboarding cost.
- Maintenance expectations are normal for your org. No releases since 2021, no dependents, no stars, and no visible issue activity means unknown compatibility with current Laravel and PHP versions, and no security response path. Verify Laravel/PHP constraints by reading
composer.json before it enters a spike, let alone a backlog item.
- You need operational tooling out of the box: dashboards, dead-letter queues, saga timeouts, replay/cancel tooling, at-scale observability. A micro-package will not supply this; expect to build it.
- A simpler, better-supported alternative matches the need:
symfony/workflow for state machines, Laravel's native event/listener model plus queued jobs for orchestration, or an external durable-execution engine (Temporal and similar) when cross-service reliability and long timers are the actual requirement.
How to Pitch It (Stakeholders)
For executives (one paragraph): Our order and onboarding flows involve several systems that can each fail halfway, and today the "what state is this customer in?" logic is scattered across controllers, listeners, and jobs. This library is a small piece of infrastructure for a known pattern — a process manager that records each step of a long-running business process and drives it to completion or cleanly unwinds it. The pattern is the right answer for reducing stuck orders and manual cleanup. The specific package, however, is effectively unmaintained: no releases since 2021, no downstream users, no community. Recommendation: do not adopt it as a dependency. Instead, treat it as a cheap, concrete reference for evaluating the pattern, and budget one engineer-week to either implement the pattern in-house on our existing event system or evaluate a supported engine. The decision to fund is about the pattern, not this package.
For engineering leads: This is Laravel wiring around Broadway sagas — a process manager that subscribes to domain events and dispatches commands. It is only defensible on top of an existing Broadway event store. Given the maintenance signals (0 stars, 0 dependents, last release 2021-09-07, MIT), I'd propose a timeboxed spike: read the provider and one saga example, confirm the concepts map to our domain, and test whether Broadway itself supports our Laravel/PHP target. If the pattern wins, we own the implementation — our own ProcessManager abstraction with a persisted state table, idempotency keys, retry/timeout policy, and compensation handlers. That is a few hundred lines we control, versus a fork of an unmaintained wrapper we'd have to babysit. If we'd rather not own orchestration at all, the honest comparison is a hosted durable-execution service, and I'd want cost and ops tradeoffs on the table before we commit.
What to tell customers/support: Nothing at this stage. This is an internal architecture decision; the customer-visible outcome is fewer stuck orders and faster recovery when a downstream provider fails, which we can promise only once the workflow work is actually funded and shipped.