Rabbitevents Laravel Package

Product Decisions This Supports

• Build vs. buy on cross-service messaging. The package is a maintained, Laravel-native layer over RabbitMQ: events are declared with attributes, publishing and consuming ride on Laravel's existing event system, and workers run through Artisan. That removes the "write our own AMQP plumbing" line item from the roadmap and replaces it with a Composer dependency plus topology design work. For a PM, this is a scope reduction on integration infrastructure, not a new product capability to sell.
• Roadmap sequencing for service extraction. It gives a Laravel monolith a cheap, incremental off-ramp: publish one new domain event to the broker, add one consumer, ship — without a platform migration or a new operational stack beyond RabbitMQ. This makes "decouple service X" plannable in sprints rather than as a single high-risk program.
• Feature enablement where async fan-out is the requirement. Notifications, audit trails, search indexing, downstream enrichment, cross-service cache invalidation — anything where one domain event must reach multiple subscribers without blocking the request path. If the roadmap has several of these queued up, this package is the common substrate underneath all of them and justifies its adoption cost once.
• Auditability and support tooling as a product requirement. The General log writer persists consumed events and their payloads, which is the building block for audit trails, replay/debug workflows, and incident forensics. Teams with compliance, billing-reconciliation, or "what did the system actually receive" support burdens can treat this as partially satisfying that requirement instead of commissioning bespoke logging.
• Prioritization of reliability work. The v9.1.3 fix (reading handler payloads via payload()) is a correctness patch in the logging path — a signal that observability correctness is being maintained upstream at low adoption cost. It argues for funding topology, retry/DLQ policy, and payload versioning in our backlog rather than assuming the library covers them; those are product-visible reliability risks (dropped events, poison-message loops, silent consumer breakage) that belong in the risk register, not in engineering's noise.
• Roadmap risk calibration. Patch-only, no breaking changes, no migration: adopting this release does not compete for engineering capacity with committed feature work. That matters when deciding whether to take the dependency this quarter versus deferring.

When to Consider This Package

Adopt when:

• The estate is Laravel/PHP services and RabbitMQ is already operated, or is the chosen broker for the next horizon. The value proposition collapses if the broker has to be introduced because of this package.
• The requirement is async fan-out of domain events between services with modest complexity — no stream processing, no joins, no schema registry.
• The team wants idiomatic Laravel listeners (DI, config-driven routing, built-in logging) rather than hand-rolled AMQP consumers, and does not have a dedicated platform team to own a bespoke bus.
• Incremental decoupling is the plan: publish new integration events first, leave in-process and existing queue-based events alone.
• Maintained-but-small open source is acceptable for a supporting integration, with the ability to fork and patch if needed.

Look elsewhere when:

• The standard is Kafka, AWS SQS/SNS, or a managed cloud event bus — the abstraction is RabbitMQ-specific and this would create a second messaging paradigm alongside Queue::push, a durable cognitive and operational tax.
• Requirements include exactly-once semantics, schema registry, or stream processing — those belong to heavier platforms, and forcing them here produces a "we'll build it on top" roadmap item that erodes the build-vs-buy case.
• A meaningful share of services is non-PHP; a Laravel-centric client is a poor fit for the whole estate and you'd end up supporting two integration paths.
• You need vendor-backed SLAs. Single-maintainer project: acceptable for supporting flows, not for a Tier-1 critical path without a documented fork/patch contingency.
• There is no named owner with RabbitMQ fluency. Failure triage needs queue depth, unacked messages, and prefetch literacy that most Laravel on-call engineers don't have. Without that owner, adoption converts a code decision into an operational liability.

Gating questions before committing roadmap capacity: is the General log writer actually enabled in our config (if not, this patch is a no-op and the auditability benefit is unrealized)? Does the fix change emitted log shape in a way that breaks existing dashboards or log-based alerting? Which versions carried the payload regression, and did it fail loudly or corrupt logs silently?

How to Pitch It (Stakeholders)

For executives. This is a small, focused, MIT-licensed dependency that lets our Laravel services talk to each other through RabbitMQ without custom integration code. It reduces engineering spend on plumbing and shortens the path to event-driven features already on the roadmap — notifications, indexing, cross-service sync — by giving them one shared substrate instead of one-off integrations. It is actively maintained; the current release is a low-risk bugfix that makes our event logs accurate, with no migration effort and no breaking changes. Two caveats worth stating plainly: it assumes RabbitMQ, so it is a fit only if that is our broker direction; and it is a small-maintainer project, so it belongs on supporting integration flows, not on a Tier-1 critical path without a fork contingency. Net: lower integration cost and better auditability, contingent on naming a RabbitMQ-capable owner before go-live.

For engineering. A thin, well-scoped layer over php-amqp that keeps producing events idiomatic to Laravel: attribute-declared events, configurable exchange/routing-key/queue topology, a middleware pipeline for filtering and retries, and rabbitevents:listen / rabbitevents:list for workers and introspection. Pin to ~9.1.3 rather than ^9 — the 9.x line is still settling its internals. The v9.1.3 fix corrects payload retrieval in the General log writer to use the payload() accessor; verify any custom log-writer overrides follow the same pattern and confirm nothing downstream parses the old log shape. Deploy consumers as their own process group, not bolted onto existing queue workers — different failure and restart semantics. The real design work is not the wiring: it's the event-to-routing-key map, exchange/queue topology under version control, retry/DLQ policy (the top operational risk — without an explicit policy, expect poison-message requeue loops), a payload version field, and an explicit decision on publisher-side behavior when the broker is unavailable. Budget roughly a day or two for a working publisher/consumer pair, one to two weeks to production-grade it.