Async Event Dispatcher Bundle Laravel Package

Product Decisions This Supports

• Async vs. synchronous eventing: whether user-facing request paths can hand off work (email, indexing, webhooks, audit fan-out) to a queue instead of blocking the response. This package is a concrete reference implementation of the "dispatch → RabbitMQ → consumer" pattern on the Symfony event dispatcher — useful as a design artifact even if the code itself is never adopted.
• Latency and reliability roadmap: quantifies the payoff of moving non-critical listeners off the request cycle — lower p95 response times, and resilience via broker persistence and retries instead of a lost event when a downstream service is down.
• Build vs. buy vs. reuse: frames the real question as "do we wire our own async dispatcher, adopt a maintained bundle, or migrate to the framework-native transport?" This package sits in the "reuse if pinned to legacy stack" bucket only.
• Legacy estate triage: presence of Symfony2-era bundles like this in a dependency graph is a platform-modernization signal. It should feed the migration backlog for PHP/Symfony upgrades, not the feature roadmap.
• Vendor and dependency governance: an unmaintained, single-organization, Bitbucket-hosted package with zero dependents and no ecosystem is a supply-chain risk decision — fork-and-own vs. replace.
• Team topology: supports the decision to split out consumer services (workers, dead-letter handling, operational ownership of queues) — async dispatch creates an operational surface that someone must own.

Recommendation: do not adopt as a dependency. Treat it as a pattern reference and a migration marker; the forward path is Symfony Messenger (or an equivalent maintained transport).

When to Consider This Package

Consider it only when all of the following hold:

• You are maintaining a Symfony 2.x application that cannot be upgraded in the near term.
• You are already operating RabbitMQ in production, with monitoring, DLQ policy, and on-call ownership in place.
• You need async event dispatch this quarter and have no appetite to build the producer/consumer glue yourself.
• You are prepared to vendor/fork the source into your own repository, own the maintenance, and pin the commit — Bitbucket hosting plus zero stars and zero dependents means no community maintenance, no security response, and no upstream support.
• The events you are moving are idempotent and tolerant of at-least-once delivery (or you add deduplication yourself).

Look elsewhere when:

• You are on Symfony 4.3+ or any modern PHP stack — use Symfony Messenger with the AMQP or Redis transport; it is framework-native, maintained, and covers retries, failure transports, and middleware.
• You need observability, tracing, or schema governance for events — this bundle will not give you serialization contracts, versioning, or metrics out of the box.
• You require vendor support, security patching, or an SLA — none exists here.
• Your event volume is low and latency is not a bottleneck — synchronous listeners plus a simple job table may be strictly cheaper to run.
• You need ordered or exactly-once semantics — neither is provided; you would be building that on top.

How to Pitch It (Stakeholders)

For executives: A team has surfaced a small, self-built Symfony 2 bundle that pushes application events into RabbitMQ so slow work happens off the request path. The pattern is sound and worth copying; the package is not. It targets a framework version that has been end-of-life for years, has no community, no dependents, and lives on Bitbucket with no maintenance commitment. We should not add it to our stack. The value here is the architectural template — and it is a useful data point that our legacy surface still runs on Symfony 2, which is the actual budget conversation.

For engineering leadership: Adopting this means owning a fork of unmaintained code on an EOL framework — a compounding liability. If we need async events on the legacy app short-term, fork it deliberately with a named owner and a removal date. The strategic path is Symfony Messenger on an upgraded runtime, which delivers the same pattern with retries, failure transports, and support. Recommend a short spike to confirm Messenger meets our throughput and routing needs, then fold the upgrade into the platform roadmap.

Message to land: "Right pattern, wrong artifact. Fund the migration, not the dependency."