Enqueue Bundle Laravel Package

Product Decisions This Supports

• Build vs. buy for messaging infrastructure. This bundle is a decision aid, not a dependency: it shows what a mature transport-abstraction layer looks like (AMQP/RabbitMQ, SQS, Redis, Azure Service Bus, STOMP) behind one API, which lets you price "build our own broker abstraction" honestly against "adopt one."
• Broker selection deferral. The abstraction lets you ship against a queue interface now and pick RabbitMQ vs. SQS vs. Redis later — useful when infra choice is blocked on cloud/vendor negotiations or on cost modelling at scale.
• Architecture roadmap: async events and RPC over MQ. The package's explicit support for RPC-over-queue and async domain events is a concrete reference for scoping an event-driven or service-decomposition initiative, including what "request/reply over a broker" costs in operational complexity versus plain HTTP.
• Vendor/exit strategy. A transport-agnostic messaging layer is an option on the broker market: it reduces lock-in to a single managed service and makes a future migration a configuration change rather than a rewrite. That is a portfolio-level decision this package informs.
• Ecosystem signal, not a feature bet. Zero stars, zero dependents, and a [READ-ONLY] subtree split of an upstream project tell you the category is real but this artifact has no adoption. That is a legitimate input to "do we invest here?" — and the answer is no, buy the upstream if you buy at all.
• Not a Laravel decision. This is a Symfony bundle. For a Laravel roadmap it only supports decisions as a reference architecture; it does not belong in a Laravel dependency graph.

When to Consider This Package

Consider (the upstream, not this split) when:

• The application is Symfony 5/6/7 and the team has already committed to Symfony's bundle/service-container conventions.
• You genuinely need multiple transports, or need to keep that option open across environments (SQS in prod, Redis locally, RabbitMQ on-prem).
• You need functionality Laravel-style queues don't cover well: RPC over MQ, cross-language consumers, non-trivial routing/exchange topologies, Azure Service Bus.
• You want a maintained abstraction rather than hand-rolling broker clients in application code.

Look elsewhere when:

• You are on Laravel. Use the native queue system — database/Redis drivers plus Horizon for Redis, or a maintained RabbitMQ driver (vladimir-yuldashev/laravel-queue-rabbitmq) if you need AMQP. Pulling a Symfony bundle into Laravel is a category error with real integration and maintenance cost.
• You require the canonical artifact. micro-module/enqueue-bundle is a read-only mirror; the maintained source is the upstream enqueue/enqueue-bundle. Adding a low-adoption republished split introduces an extra maintainer into your supply chain for zero functional gain — that is a third-party-risk finding, not a feature.
• One broker, modest volume. If you will only ever use SQS or only ever use Redis, the abstraction is pure overhead; a thin adapter is cheaper to own and easier to debug at 3 a.m.
• You need strong adoption guarantees. Zero stars and zero dependents means no community signal, no third-party security review, and no evidence of production use. If your procurement or SCA process gates on adoption, it fails here.
• You need vendor-backed support. MIT community project; no SLA, no support contract.

How to Pitch It (Stakeholders)

To executives: There is a real strategic question behind this package — should our messaging layer be broker-agnostic? An abstraction buys option value: we can move between RabbitMQ, SQS and Redis without rewriting application code, which materially lowers switching cost if cloud pricing or vendor strategy changes. But the artifact itself is a zero-adoption, read-only mirror of a community Symfony bundle with a single maintainer and no support contract. Recommendation: adopt the pattern, not the package. If we pursue broker abstraction, we do it through the established upstream project or a first-party adapter, and only if we are on Symfony.

To engineering: Capability-wise this covers the checklist — multiple transports, async events, RPC over MQ, Symfony bundle integration. The blockers are structural: it is a Symfony bundle (wrong runtime for our Laravel services), it is a [READ-ONLY] subtree split rather than the canonical package, and it has no dependents. If a team wants the Enqueue ecosystem, they should depend on the upstream and we should review that decision on its own merits. If a team just needs background jobs, the native Laravel queue plus Horizon already covers it, and we should say so before anyone files a ticket.

Net: Low-priority, informational. Use it to frame the broker-abstraction conversation; do not approve it as a dependency.