Laravel Queue Laravel Package

Product Decisions This Supports

Broker choice as a product capability, not an infrastructure detail. Laravel ships queue drivers for database, Redis, SQS, and Beanstalkd — but not RabbitMQ, Kafka, or Google Pub/Sub. This package is the adapter that lets you run the same dispatch(), job classes, and queue:work workflows on those brokers. That unlocks product decisions like:

• Enterprise/on-prem deployments. If a customer segment (regulated, healthcare, public sector, large EU accounts) mandates RabbitMQ or Kafka because it's already their golden-path messaging standard, this is the cheapest path to "yes" without forking your job architecture.
• Multi-cloud and exit-cost reduction. Abstracting the queue backend behind Enqueue means your roadmap isn't hostage to one vendor's SDK. Relevant when a deal or a data-residency requirement pushes you off a hyperscaler's native queue.
• Delivery guarantees you can't cheaply build yourself. Dead-letter queues, per-message TTL, priority queues, routing keys, consumer groups, and delayed retries are broker features. Adopting this package lets you sell reliability ("guaranteed at-least-once processing with DLQ replay") instead of building retry bookkeeping into application code.
• Build vs. buy on the driver layer. The alternative is writing and maintaining a custom Illuminate\Queue\Queue driver per broker. Enqueue gives you one adapter for ~8 transports; the trade is a third-party abstraction you don't control.
• Migration sequencing. It is a strangler-fig enabler: you can move a single queue (e.g. high-value notification jobs) onto RabbitMQ while the rest of the app stays on Redis, then expand. That's a roadmap-friendly, low-blast-radius migration story.
• Use cases that justify the spend: per-tenant queue isolation for noisy-neighbor control; fan-out/event streaming where Kafka is already the company bus; hybrid cloud where app tier and broker live in different environments; workloads needing message-level audit trails a broker provides natively.

What it does not decide for you: observability. Laravel Horizon is Redis-only, so choosing this path means losing Horizon's dashboard and metrics and substituting the broker's own tooling (RabbitMQ Management, Kafka UI) or a paid APM. Budget for that in the same decision, not later.

When to Consider This Package

Consider it when most of these are true:

• You have a named, funded requirement for a broker Laravel doesn't support natively (RabbitMQ/AMQP, Kafka, Pub/Sub, STOMP) — not a hypothetical "we might need portability."
• The broker is already operated by someone — a platform/SRE team, or a managed service (Amazon MQ, CloudAMQP, Confluent). This package is the app-side adapter; it is not an operations strategy.
• Your team is willing to own the dependency risk: 240 stars, effectively zero dependent packages, and roughly annual releases mean you should expect to vendor/fork it, pin versions, and validate against each Laravel upgrade yourself.
• You need broker semantics in the product (DLQ replay, priorities, routing, delayed delivery) and would otherwise hand-roll them.
• You're doing a staged migration and want to keep Laravel's job API stable while the transport changes underneath.
• You've confirmed Laravel/PHP version compatibility and transport maturity for your specific broker with a spike — not from the README.

Look elsewhere when:

• You just need queues. Laravel's first-party Redis/SQS/database drivers are better supported, better documented, and Horizon-compatible. Default to them; a 240-star adapter is not an upgrade for its own sake.
• Horizon is load-bearing for your ops or on-call rotation and you're not prepared to replace it.
• You have no messaging operations capability. A broker you can't run, monitor, and page on is worse than Redis you can.
• You need enterprise support, SLAs, or a security review trail. MIT with a small maintainer base won't satisfy a procurement questionnaire; a commercial broker's official SDK might.
• Throughput/latency is the core requirement and you'd be tuning an abstraction layer you don't control.
• A vendor-native Laravel integration already exists for your broker — prefer the shortest dependency chain.

Adoption gate (suggested): a 1–2 week spike proving (a) jobs dispatch and process on the target broker with your real payloads, (b) failure/retry/DLQ behavior matches your reliability claims, (c) you have a monitoring story, (d) upgrading Laravel doesn't break it. If the spike can't clear all four, the answer is no.

How to Pitch It (Stakeholders)

For executives — one paragraph: This is a small open-source adapter (MIT, no license cost) that lets our existing Laravel job code run on enterprise-grade message brokers like RabbitMQ and Kafka instead of only Redis or SQS. It removes a structural blocker to selling into customers who mandate those brokers and reduces our dependence on any single cloud vendor's queue. The engineering cost is low — it's an adapter, not a rewrite — but it introduces a lightly-maintained third-party dependency and requires us to replace Horizon's monitoring with broker-native tooling. Recommendation: approve a two-week technical spike against one real broker and one real customer requirement; treat the package as a thin, pinnable layer we're prepared to fork, not a platform bet.

For engineering — the ask and the trade: Keep Laravel's queue API as the contract; swap the transport. You get one adapter across AMQP/Kafka/Pub-Sub/STOMP and the broker's native DLQ, priority, and routing semantics. In exchange: pin the version and the underlying Enqueue transport packages, add integration tests against a containerized broker, replace Horizon with broker dashboards plus your own metrics, and budget a day per Laravel upgrade to re-verify. If the spike shows meaningful maintenance drag, the fallback is a ~200-line custom driver for the one broker we actually need — cheaper than an abstraction we don't fully use.

Framing to avoid: don't sell this as "future-proofing" or "portability insurance." Sell it against a specific named broker requirement with a specific customer or deployment target attached — that's the only version of this pitch that survives a prioritization review.