Simple Bus On Steroids Laravel Package

Product Decisions This Supports

• Event-Driven Architecture (EDA) Adoption: Enables scalable, decoupled microservices or modular monoliths by ensuring reliable asynchronous event processing.
• Data Consistency & Integrity: Supports event sourcing patterns by guaranteeing events are persisted atomically with entity state changes, reducing data corruption risks.
• Resilience & Fault Tolerance: Mitigates failures via transactional subscribers, dead-letter queues (DLQ), and retry mechanisms, critical for mission-critical workflows (e.g., payments, notifications).
• Observability & Debugging: Adds correlation IDs, event IDs, and occurrence timestamps, simplifying tracing across distributed systems (aligns with OpenTelemetry/SLOs).
• Build vs. Buy: Avoids reinventing transactional event processing, RabbitMQ integration, or DLQ logic—reduces dev time by 30–50% for async workflows.
• Roadmap Priorities:
  • Phase 1: Implement async eventing for non-critical workflows (e.g., analytics, notifications).
  • Phase 2: Roll out to core workflows (e.g., order processing) with DLQ monitoring.
  • Phase 3: Extend to event sourcing for auditability/replayability.

When to Consider This Package

Adopt If:

• Your system relies on asynchronous event processing (e.g., Laravel + RabbitMQ/Redis queues).
• You need transactional guarantees for event subscribers (e.g., "Process payment and send receipt" as a single unit).
• Event sourcing is a priority (events persist with entity state in the same transaction).
• You lack dedicated SRE/DevOps to manage DLQs, retries, or RabbitMQ tuning.
• Your team uses SimpleBus or wants a lightweight alternative to Symfony Messenger/Laravel Horizon.

Look Elsewhere If:

• You’re not using RabbitMQ (package is RabbitMQ-centric; alternatives like Pulsar/Kafka may need adapters).
• Your events are fire-and-forget (no need for retries/DLQs; use native Laravel queues).
• You require exactly-once processing (this handles per-subscriber transactions, not end-to-end deduplication).
• Your stack is non-PHP (e.g., Node.js, Go—consider EventStoreDB/Kafka Streams).
• You need advanced event schema validation (e.g., JSON Schema; pair with Spatie’s Laravel Event Dispatcher).

How to Pitch It (Stakeholders)

For Executives:

*"This package lets us safely scale async workflows without building custom retry/DLQ systems—saving [X] dev months and reducing failure-induced outages. For example:

• Payments: If a fraud check fails, the order still completes (subscriber isolation).
• Notifications: Missed emails are auto-requeued, not lost (DLQ + retries).
• Compliance: Events are timestamped/correlated, simplifying audits. Cost: Free (MIT license). Risk: Minimal—uses proven SimpleBus under the hood."*

For Engineering:

*"Pros:

• Atomic event persistence: Events saved in the same DB transaction as entity changes → no lost events.
• RabbitMQ offloading: Async workers pull events from DB, reducing queue lag.
• Built-in resilience: Configurable retries/DLQs (e.g., max_retries=3, dead_letter_exchange=failed_events).
• Debugging: Correlation IDs let you trace event chains (e.g., OrderCreated → PaymentProcessed → NotificationSent).

Tradeoffs:

• RabbitMQ dependency: Not ideal if you’re queue-agnostic.
• Learning curve: SimpleBus concepts (e.g., decorators, handlers) may need onboarding.
• No built-in metrics: Pair with Prometheus/Laravel Telescope for observability.

Next Steps:

1. Pilot: Use for a non-critical event (e.g., UserRegistered → SendWelcomeEmail).
2. Monitor: Track DLQ volume/retries in the first 2 weeks.
3. Scale: Roll out to core workflows if stability holds.

Alternatives Considered:

• Symfony Messenger: More features but heavier (~200MB vs. ~5MB).
• Custom solution: Would take 2–3 sprints to build equivalently."*