Rabbitmq Bundle Laravel Package

Product Decisions This Supports

• Async workload offloading — anything that shouldn't block an HTTP request: transactional email, PDF/image generation, exports, webhook fan-out, third-party sync. This is usually the reason a PM signs off on a broker at all; the bundle turns "build a messaging layer" into a configuration change.
• Event-driven decoupling between Symfony services — one service publishes order.placed, others consume. Lets you carve workers out of a monolith on your own schedule instead of a big-bang rewrite.
• Roadmap acceleration vs. build — declarative config for connections, exchanges, queues, bindings, producers, consumers, and RPC. The "messaging plumbing" ticket becomes hours, not a sprint. You're not buying anything, but you are avoiding a bespoke AMQP wrapper your team would own forever.
• Reliability and back-pressure decisions — delayed messages, retry/dead-letter topology, consumer supervision. Directly supports SLAs on background processing, often the hidden dependency behind "we can't scale past X." New in v1.15.1: multiple hosts per connection, i.e. the failover lever a PM reaches for when "RabbitMQ is a single point of failure" shows up in an SLA review.
• Use cases to scope: email spooling, media transcoding, search indexing, scheduled batch fan-out, inter-service commands where synchronous HTTP coupling has already caused incidents.

Caveat: the capability is real; the health of this distribution is still thin. 0 stars, 0 dependents, and v1.15.1 is the first release since June 2021 — a two-line change set (multi-host connections, a service-classname fix in rabbitmq.xml). One release after four years is a pulse, not a maintenance commitment. Frame the decision as "should we standardize on this fork," and assume the answer is no for anything new. Note also that the classname fix implies the shipped service definition was previously wrong in at least one configuration — worth confirming which.

When to Consider This Package

Reasonable to consider when:

• You already run oldsound/rabbitmq-bundle or a derivative in production and this fork is what's actually installed. Then the real decision is "stay vs. migrate," and the migration is the thing worth funding.
• Broker HA was the specific blocker holding you back: v1.15.1's multi-host support is the first capability addition in years and is genuinely useful for failover. Still validate the semantics — config keys for multiple hosts do not by themselves prove reconnect/failover behavior, and duplicate config is easy to get wrong.
• Your team is Symfony-native and wants config-file-driven topology (exchanges, queues, bindings, producers, consumers as services) rather than hand-wiring php-amqplib channels per project.
• You need RPC request/reply or delayed messages as first-class config rather than custom code.
• The surface area you depend on is narrow and you're willing to vendor/fork it yourself.

Look elsewhere when:

• Greenfield work. Use Symfony Messenger (first-party, maintained, transport-agnostic) or the maintained upstream successor, php-amqplib/rabbitmq-bundle. Same ergonomics, live maintainer, real security-triage path — and Messenger's AMQP DSN already accepts multiple hosts, so v1.15.1's headline feature is not a differentiator.
• You need current Symfony/PHP support — a new release with no compatibility statement does not resolve this; verify explicitly against your version matrix.
• You need a support contract, CVE response, or a dependency your security review will accept. Zero dependents means zero community eyes, and one release does not change that.
• Messaging needs are simple (fire-and-forget jobs) — a broker plus bundle may be over-engineering versus a database-backed queue.
• You're not already committed to RabbitMQ. Transport choice deserves its own decision before library choice.

Adoption gate: is this package load-bearing for a roadmap capability, and does it survive a 30-minute spike on your current Symfony/PHP version? If HA is why you're looking, extend the spike to kill a broker mid-flight and confirm the multi-host path actually fails over. If it fails, the answer is Messenger.

How to Pitch It (Stakeholders)

Executives (one paragraph): This is a small open-source connector that lets our Symfony application hand work to RabbitMQ instead of doing it inside the web request — the mechanism behind faster page loads, reliable background processing, and services that can scale or split independently. A new release adds broker multi-host support, which is a real step toward failover. The pattern is standard and worth investing in; this specific package remains a low-adoption fork with a single release since 2021, so I recommend we adopt the pattern via Symfony Messenger or the maintained upstream bundle rather than build a dependency on this one. Because it's a thin configuration layer over php-amqplib, switching cost is low — this is a contained technical decision, not architectural lock-in.

Engineering: The value is declarative topology plus consumer plumbing registered as Symfony services; nothing here is proprietary or hard to replicate. v1.15.1 adds multi-host connections and fixes a service classname — no breaking changes, no deprecations, so it is a safe patch-level bump if we're already installed. Don't read it as a revival: two line items is not a roadmap. Run a short compatibility spike against current Symfony/PHP. If we're already on it through the oldsound lineage, scope a Messenger migration ticket now while the footprint is small — cost scales with the number of producers and consumers, not with time. If multi-host was the reason we stayed, note that Messenger covers it.

Security/compliance: 0 stars, 0 dependents, no release between June 2021 and v1.15.1 — no continuous triage and no evidence of a security process. Acceptable only as a known, inventoried exception with a documented exit path and a named owner; the new release is not grounds to close that exception.