Broadway Saga Laravel Package

Technical Evaluation

Architecture Fit

• Saga Pattern Alignment: The package implements the Saga pattern, which is ideal for distributed transactions in microservices or event-driven architectures. It fits well with Laravel’s event system (e.g., Illuminate\Events) and queue workers (e.g., Illuminate\Queue).
• Broadway Integration: Since it’s a Broadway extension, it assumes an event-sourcing foundation. If the Laravel app already uses event sourcing (e.g., via spatie/laravel-event-sourcing), this package could integrate cleanly. If not, additional abstraction may be needed.
• State Management: Sagas require compensating transactions for rollbacks. This package likely handles this via Broadway’s command bus, which may introduce complexity if Laravel’s native queue system is already in use.

Integration Feasibility

• Laravel Compatibility: The package is PHP-based but not Laravel-specific, meaning:
  • Pros: Works with any PHP app using Broadway.
  • Cons: Requires Broadway (broadway/broadway) as a dependency, which may not be natively Laravel-friendly (e.g., no Eloquent ORM integration).
• Event/Command Bus Overlap: Laravel’s Bus facade (for commands) and Events system could conflict with Broadway’s command bus. A wrapper layer may be needed to reconcile the two.
• Database Requirements: Broadway relies on Doctrine DBAL for persistence. Laravel’s Eloquent or Query Builder would need adaptation unless using Doctrine’s Laravel bridge (doctrine/dbal).

Technical Risk

• Tight Coupling to Broadway: If the app isn’t already using Broadway, introducing it just for Sagas adds unnecessary complexity.
• Rollback Complexity: Sagas require idempotency and compensating actions. If Laravel’s transaction manager isn’t aligned with Broadway’s, race conditions or inconsistent state could occur.
• Testing Overhead: Saga workflows are hard to test in isolation. Mocking Broadway’s command bus in Laravel’s PHPUnit tests may require custom fixtures.
• Performance: If Sagas involve long-running workflows, Laravel’s queue system (e.g., Redis, database) may not optimize for Broadway’s event-sourced state.

Key Questions

1. Does the app already use event sourcing? If not, is there a business case for adopting Broadway just for Sagas?
2. How does this fit with Laravel’s existing queue/worker system? Will we need a hybrid approach (e.g., Broadway for Sagas, Laravel Queues for other jobs)?
3. What’s the rollback strategy? Are compensating transactions idempotent, and how will they integrate with Laravel’s database transactions?
4. Monitoring & Observability: How will we track Saga progress in Laravel Horizon or Sentry? Broadway may need custom logging.
5. Team Familiarity: Does the team have experience with Broadway/Event Sourcing? If not, ramp-up time could delay adoption.

Integration Approach

Stack Fit

• Best Fit: Apps using:
  • Broadway (event sourcing).
  • Laravel with Doctrine DBAL (for Broadway persistence).
  • Event-driven architectures (e.g., CQRS, microservices).
• Workarounds Needed: If using Eloquent-only, a Doctrine bridge (laravel-doctrine/orm) or custom repository layer would be required.
• Alternatives: If Broadway is overkill, consider:
  • Laravel’s native queues + custom compensating actions.
  • Packages like spatie/laravel-transactional-messages for simpler workflows.

Migration Path

1. Phase 1: Proof of Concept
   • Set up Broadway alongside Laravel (e.g., in a separate service).
   • Implement one critical Saga to validate integration.
   • Test rollbacks and event sourcing consistency.
2. Phase 2: Hybrid Integration
   • Use Laravel’s queue system for non-Saga jobs.
   • Route Saga-specific commands through Broadway.
   • Implement a command bus adapter to bridge Laravel’s Bus and Broadway’s CommandBus.
3. Phase 3: Full Adoption
   • Migrate all distributed transactions to Sagas.
   • Replace manual compensating logic with Broadway’s built-in handlers.
   • Optimize persistence (e.g., shared Doctrine DBAL config).

Compatibility

Sequencing

1. Infrastructure Setup
   • Install broadway/broadway and broadway/broadway-saga.
   • Configure Doctrine DBAL (if not already in use).
2. Command Bus Integration
   • Create a Laravel service provider to bind Broadway’s CommandBus.
   • Implement a command dispatcher to route Laravel commands to Broadway.
3. Saga Workflow Definition
   • Define Saga steps as Broadway commands.
   • Implement compensating actions for rollbacks.
4. Testing & Validation
   • Write Pest/PHPUnit tests for Saga workflows.
   • Test edge cases (e.g., failed steps, retries).
5. Deployment
   • Roll out Broadway workers alongside Laravel queues.
   • Monitor Saga completion rates and failure logs.

Operational Impact

Maintenance

• Dependency Management:
  • Broadway and its extensions require regular updates, which may introduce breaking changes (last release was 2020).
  • MIT License is permissive, but abandoned packages pose long-term risk.
• Debugging Complexity:
  • Sagas span multiple commands/events, making stack traces harder to follow.
  • Broadway’s event store adds another layer of data to inspect.
• Tooling Gaps:
  • No native Laravel Horizon support for Broadway workers.
  • Logging may require custom setup (e.g., Monolog bridges).

Support

• Learning Curve:
  • Team members unfamiliar with event sourcing or Broadway will need training.
  • Documentation for the package is minimal (typical for niche libraries).
• Vendor Lock-in:
  • Heavy reliance on Broadway’s internals could make future migrations difficult.
• Community:
  • Low stars (35) suggest limited adoption; support may be community-driven.

Scaling

• Horizontal Scaling:
  • Broadway’s event store must be shared (e.g., PostgreSQL, Redis).
  • Worker scaling follows Laravel’s queue patterns but may need Broadway-specific tuning.
• Performance Bottlenecks:
  • Event sourcing can lead to high read volumes (all state changes are stored).
  • Compensating transactions may add latency if not optimized.
• Cost:
  • Additional database storage for event logs.
  • Potential overhead if Sagas are overused for simple workflows.

Failure Modes

Ramp-Up

• **Onboarding