Queue Bundle Laravel Package

Product Decisions This Supports

• Build vs. buy for background-job infrastructure. The bundle's one substantive idea is a transport-agnostic job interface (JobManagerInterface) sitting over Redis, RabbitMQ, Beanstalkd, Doctrine ORM/MySQL, Doctrine ODM/Mongo, and custom backends, plus a unified worker command. That is an argument for deferring the "which broker do we standardize on?" decision — not for adopting this package. The same deferral is achievable on Laravel queue connections with no new dependency.
• Framework-fit is the gating decision, and it closes early. This is a Symfony 2/3/4/5 bundle — Bundle class, DI extension, compiler passes, YAML config tree, dtc:queue:run console command. There is no service provider, facade, or Illuminate\Queue contract surface. On a Laravel target the evaluation ends at "incompatible," because native queues plus Horizon already cover database, Redis, SQS, and Beanstalkd with first-party support.
• Migration mapping. If we ever inherit or absorb a Symfony service, the abstraction gives us a ready conversion plan: JobManagerInterface transports → Laravel queue connections, job classes → ShouldQueue jobs, dtc:queue:run → queue:work under Supervisor, bundle dashboard → Horizon or a failed-jobs view. Behavioral parity in days, not weeks.
• Scoping "run this in the background" features. Supported use cases: transactional email, webhook retries, report/PDF generation, image processing, scheduled exports. The PM-relevant part is the cost line — every supported transport is something the team must operate, monitor, and patch. Multi-backend flexibility is also multi-backend ops surface.
• Dependency-risk framing. 120 stars, 0 dependents, single maintainer, support ceiling at Symfony 5 (EOL), opportunity score 41.6. For a PM that reads as a reference implementation, not a platform commitment — a signal to harvest the design, not the code.
• Ops-feature gap analysis. If the roadmap needs bounded retries, dead-letter handling, worker autoscaling, dashboards, and alerting, that is a buy decision (Horizon or a managed broker). The bundle covers part of it and leaves the rest to us.

When to Consider This Package

Consider it when:

• You are on Symfony 4/5 with Doctrine in place and want multi-transport queueing without committing to one broker.
• You genuinely run heterogeneous backends — e.g., Mongo/ODM for a legacy service and MySQL/ORM for a new one — behind a single job API.
• You want per-environment transport swapping (synchronous in dev/test, Redis or RabbitMQ in production).
• You prefer Doctrine entities for queue state over standing up a separate broker.
• You want to read the source for its job-status lifecycle and stalled-job recovery pattern, regardless of whether you adopt it.

Look elsewhere when:

• You are on Laravel or any non-Symfony stack. Use native queues and Horizon; do not bolt a Symfony bundle onto a Laravel app.
• You are starting greenfield on Symfony 6/7 or PHP 8.1+. Support ends at Symfony 5 — you would adopt an EOL dependency on day one.
• You need only one transport. A direct Redis/SQS client or a managed queue is simpler and better supported than an abstraction over six backends.
• You need real operational features — retries with DLQ, autoscaling workers, dashboards, alerting, an SLA. That is a platform buy, not a bundle.
• Maintenance risk tolerance is low. 0 dependents and a single maintainer mean every future PHP upgrade becomes our patch to write.

How to Pitch It (Stakeholders)

Executive summary. This is a small, MIT-licensed Symfony bundle that abstracts background job queues across Redis, RabbitMQ, Beanstalkd, MySQL/Doctrine, and MongoDB, with a built-in worker command, delayed jobs, retries, pluggable serializers, and a job dashboard. Its one real idea is that job code should not know which broker it runs on — so you can start with a database-backed queue and graduate to a real broker without rewriting application code. That is a legitimate pattern and worth knowing about.

It is not a fit for us. It is a Symfony 2–5 bundle and we are on Laravel; our framework already ships this capability natively, with first-party maintenance and better observability through Horizon. It also stops at Symfony 5, so even a Symfony team starting today would adopt an end-of-life dependency. With 0 dependents and a single maintainer, the support risk outweighs the value of the abstraction.

Recommendation: do not adopt as a dependency. Treat it as a reference design. If we ever need a swappable transport layer, reproduce the pattern — a transport-agnostic job contract with pluggable drivers, an explicit status lifecycle, and scheduled stalled-job recovery — on top of Laravel's queue component in a few hundred lines, with no new third-party risk and no divergence from the framework.

Engineering takeaway: zero new dependencies, zero maintenance burden, same capability delivered by the stack we already run. Action: close the evaluation, capture the job-status/recovery pattern in our design notes, and revisit only if a hard Doctrine ODM/Mongo requirement appears in an inherited Symfony estate.