Async Event Dispatcher Laravel Package

Product Decisions This Supports

• Decoupling Event-Driven Architecture: Enables asynchronous event handling to improve system scalability and responsiveness, particularly for high-throughput applications (e.g., real-time notifications, background jobs, or analytics pipelines).
• Roadmap for Microservices: Supports a "fire-and-forget" strategy to align with event-driven microservices, reducing coupling between services and enabling independent scaling.
• Build vs. Buy: Justifies buying this lightweight package over building a custom async event system, especially if RabbitMQ or file-based persistence is already in use.
• Use Cases:
  • Background Processing: Offload non-critical tasks (e.g., sending emails, generating reports) to async listeners.
  • Pub/Sub Systems: Integrate with existing message brokers (RabbitMQ) for event distribution without blocking the main application flow.
  • Legacy System Modernization: Gradually introduce async patterns to monolithic PHP apps using Symfony’s EventDispatcher (which this package extends).

When to Consider This Package

• Adopt if:
  • Your system already uses Symfony’s EventDispatcher and needs async support.
  • You’re leveraging RabbitMQ (or want to add it) for event-driven workflows.
  • Low-latency async processing is critical, but you lack dedicated queue workers (e.g., no Laravel Queues or Redis).
  • You need a simple, MIT-licensed solution with minimal boilerplate (no heavy frameworks like Laravel Horizon).
• Look elsewhere if:
  • You require built-in retries, dead-letter queues, or advanced monitoring (consider Laravel Queues, RabbitMQ directly, or Pulsar).
  • Your team lacks PHP/RabbitMQ expertise (this package has no dependents and is archived; maintenance risk exists).
  • You need multi-language support (this is PHP-only).
  • You’re building a serverless or Kubernetes-native system (prefer event bridges like AWS SNS/SQS or NATS).

How to Pitch It (Stakeholders)

For Executives: "This package lets us offload event processing to background workers (via RabbitMQ) without rewriting our existing event system. It’s a lightweight way to improve performance for non-critical tasks—like sending notifications or logging analytics—while keeping our codebase simple. Since it’s MIT-licensed and integrates with our current Symfony events, it’s a low-risk way to adopt async patterns. We’d avoid reinventing the wheel and reduce coupling between services."

For Engineers: *"The AsyncEventDispatcher wraps Symfony’s EventDispatcher to support async listeners (RabbitMQ or file-based). It’s useful if you want to:

• Decouple event handling (e.g., dispatch an event and let listeners process it later).
• Avoid blocking the main app thread (e.g., for heavy computations or external API calls).
• Extend easily—you can add custom drivers (e.g., for Kafka or database queues) by implementing AsyncEventDriverInterface. Tradeoff: It’s archived with no dependents, so we’d need to vet RabbitMQ reliability ourselves. For now, it’s a proof-of-concept for async events before we invest in a full queue system."*