Resque Queue Driver Bundle Laravel Package

Technical Evaluation

Architecture fit. This is not a Laravel package — it is a Symfony bundle (mcfedr/resque-queue-driver-bundle) that plugs a Redis-backed Resque driver into mcfedr/resque-bundle. It depends on Symfony's bundle registration, DI container, Configuration tree, and compiler passes, none of which exist in Laravel's service-provider lifecycle. Laravel's queue abstraction (Illuminate\Queue\Queue, ConnectorInterface, Worker) is a different contract entirely, so the bundle cannot be composer require'd into a Laravel app and "just work." Architecturally, Laravel already ships a mature Redis queue driver plus Horizon (supervision, retries, metrics, dashboards), so the bundle's core value proposition is redundant inside a Laravel stack.

Integration feasibility. Low. Three viable paths, in descending order of sanity:

1. Do not adopt — use Laravel's native Redis driver + Horizon. Zero integration cost.
2. Reimplement the wire format — if the real requirement is interop with an existing Resque worker fleet (Ruby or PHP), write a ~150–250 line custom Laravel connector that pushes Resque-compatible JSON payloads (class, args, queue, id) onto resque:queue:<name> lists. This captures the only genuinely useful part of the bundle without the Symfony baggage.
3. Bridge the bundle — instantiate Symfony components inside Laravel and hand-roll an adapter. High effort, fragile, and still inherits the upstream abandonment risk.

Technical risk. High. Last release was 2018-02-24, stars are 0, dependents are 0, and the score of 0.09 reflects that. Composer constraints almost certainly cap PHP at 7.x and Symfony at 2.8/3.x/4.x, which will conflict with Laravel 10/11 (PHP 8.1+). The underlying php-resque lineage is itself largely dormant. There is no CVE monitoring, no maintainer response path, and no community to validate behavior against. Forking means we own the maintenance permanently.

Key questions.

• What concrete problem does Resque solve that Horizon does not? (If the answer is "nothing," stop here.)
• Is there a hard requirement to share a Redis namespace with an existing Resque worker fleet, and is that fleet Ruby or PHP?
• What PHP and Laravel versions are in scope, and does the bundle even resolve under them?
• Is the fork-per-job (pcntl) execution model acceptable on our container runtime (Fargate/Cloud Run generally are not friendly to forking workers)?
• Who owns the fork if we adopt it, and what is the exit plan?

Integration Approach

Stack fit. Poor for Laravel, acceptable only for legacy Symfony 3.x/4.x estates. The bundle's assumptions — Symfony kernel boot, bundle config merging, event dispatcher — do not map onto Laravel's container. If the organization runs both Symfony and Laravel, this bundle belongs only on the Symfony side; the Laravel side needs its own connector.

Migration path. If we are moving a Symfony service off this bundle onto Laravel: (1) enumerate every job class and its payload shape, (2) map each to a Laravel ShouldQueue job, (3) run the new Laravel workers against the same Redis lists during a dual-consumer window using a shared payload contract, (4) drain and decommission the Symfony workers, (5) remove the bundle. If we are moving toward Resque from Laravel, reverse the direction but keep the same dual-consumer window.

Compatibility. Verify early: PHP constraint vs. our runtime, Symfony version pins, ext-redis vs. predis, ext-pcntl availability, and Redis server version (Resque assumes BLPOP semantics and specific key naming). Laravel's Redis queue uses different keys (queues:default, queues:default:delayed, queues:default:reserved), so nothing is shared by default — the connector must translate.

Sequencing. Two-week spike: week 1, confirm the interop requirement and prototype a Laravel ResqueConnector against a staging Redis with a real Resque worker; week 2, load-test payload compatibility, failure/retry behavior, and decide adopt-vs-reimplement. Do not begin with "install the bundle."

Operational Impact

Maintenance. Effectively unmaintained. Any adoption implies an internal fork, a named owner, a pinned PHP/Symfony matrix, and a documented patch process. Budget ongoing engineering time, not a one-off integration.

Support. No vendor, no community, no issue triage. Escalation is internal only. The zero-dependent count means no third-party field reports to lean on when behavior surprises us.

Scaling. Redis becomes a harder single point of failure than with Horizon, since there is no built-in supervision, autoscaling signal, or backpressure. Resque's fork-per-job model has high per-job memory overhead and poor fit for cgroup-constrained container platforms. No native metrics; observability would be a custom build.

Failure modes. Silent job loss on worker SIGKILL (no visibility timeout equivalent to Laravel's retry_after), duplicate execution when a reserved job is re-queued, unbounded failed list growth, Redis eviction silently discarding queued work, and payload schema drift between producers and consumers during any migration. Each of these needs an explicit mitigation before production.

Ramp-up. Documentation is thin and the team is unlikely to know Resque semantics (queues, workers, resque:failed, resque:stat). Expect 1–2 engineer-weeks of ramp-up for a capability Laravel already provides out of the box.

Recommendation. Do not adopt the bundle. Treat it as a specification for Resque's Redis wire format, and if cross-system interop is genuinely required, implement a small, owned Laravel connector against that format. Otherwise, standardize on Laravel's Redis queue with Horizon and close the evaluation.