Php Resque Laravel Package

Technical Evaluation

What it is: resque/php-resque is a PHP port of Ruby's Resque — a Redis-backed, fork-per-job background worker system. Jobs are JSON payloads pushed onto Redis lists (resque:queue:<name>); worker processes BLPOP a job and fork() a child to execute it. It is a standalone library, not a Laravel package: no service provider, no facade, no Laravel queue driver.

Architecture fit:

• Fits only where Laravel's first-party queue stack (database/redis/SQS drivers + Horizon) is insufficient. The genuine differentiator is payload-level interoperability with Ruby Resque, enabling a single queue consumed by both PHP and Ruby workers — relevant for polyglot estates or teams migrating off a Rails/Resque backend.
• Does not fit as a general-purpose replacement for Laravel queues. Choosing it means operating a second, parallel job paradigm alongside (or instead of) Illuminate\Queue, with its own worker lifecycle, failure handling, and tooling.
• Requires ext-redis (phpredis), ext-pcntl, and ext-posix; Linux/Unix only. This constrains container base images and rules out Windows dev parity and some serverless runtimes (no long-lived forking workers on Lambda/Fargate-style ephemeral compute without re-architecture).

Integration feasibility: Feasible but not turnkey. Two realistic paths:

1. Sidecar service (low effort, low coupling): run php-resque workers as a separate process/deployment that boots Laravel's container just enough to resolve job classes. Fast to prove, but duplicates deployment and config concerns.
2. Custom Laravel queue driver (higher effort): implement Illuminate\Contracts\Queue\Queue (push/pop/size/later) plus a worker that maps to Laravel's Worker/Job contracts so events, middleware, and failed() hooks work. This is the "correct" integration and the only one that gives a native developer experience — estimate 3–6 engineer-weeks including tests and failure-path parity.

Technical risk (medium-high):

• Small maintainer base (233 stars). The 2025-03-04 release signals recent activity, but bus-factor and security-patch latency are real. Assume you may need to vendor/fork.
• No native delayed jobs, retries with backoff, or visibility timeout. Resque's model is at-least-once with a manual/plugin retry queue; nothing equivalent to Horizon's retry/backoff/timeout policy out of the box. These must be built or accepted as gaps.
• Fork-per-job semantics bring memory growth, zombie/orphan processes, and signal-handling edge cases that Laravel's prefork workers handle more predictably.
• Payload trust: job class names are read from Redis and instantiated. A compromised or shared Redis becomes remote code execution surface; there is no payload signing.
• Redis coupling: queue durability depends on maxmemory-policy noeviction. A shared Redis instance with an LRU policy silently drops jobs — a classic, hard-to-diagnose outage.

Key questions to resolve before committing:

1. Is Ruby/Resque interoperability an actual requirement today, or a hypothetical? If hypothetical, this package is almost certainly the wrong default versus redis driver + Horizon.
2. Who owns the worker runtime in production (platform team vs. product team), and what supervises it — systemd, Supervisor, Kubernetes?
3. What is our tolerance for a community-maintained dependency on the critical path, and are we prepared to fork?
4. Which environment constraints (PHP 8.x version, Linux-only, no serverless) does this impose on our deployment targets?
5. Do we need delayed jobs, per-job retry policies, or unique-job guarantees? If yes, quantify the build cost.

Integration Approach

Stack fit: Laravel 10/11/12 on PHP 8.1+ with an existing Redis instance. Because most Laravel stacks already run Redis for cache/sessions, the infrastructure delta is small; the conceptual delta — a second queueing system — is the real cost. Use a dedicated Redis database index or key prefix so resque:* keys never collide with Laravel's queues:*/laravel_database_* keys, and never share an eviction-policy-sensitive instance with cache workloads.

Migration path (only if a driver is required beyond the POC):

1. POC (1–2 weeks): standalone worker, one low-risk queue (transactional email or report generation), production-shaped Redis, measured with existing observability. Success criteria: throughput, failure visibility, deploy-restart behavior.
2. Abstraction: introduce a custom ResqueConnector + ResqueQueue implementing the Laravel Queue contract, and a ResqueWorker mapping to Illuminate\Contracts\Queue\Job so failed(), $tries, and middleware behave as engineers expect.
3. Job portability: keep job classes framework-agnostic (handle()-style entry points) so they can move back to the native driver if the pilot fails. Treat this as a reversible bet.
4. Cutover per queue, not big-bang: dual-write is not possible in a queue system, so migrate queue-by-queue with a drain-then-switch procedure.

Compatibility considerations:

• Ruby ↔ PHP payload parity must be explicitly tested (class name mapping, argument shapes, exception/failure metadata). Interop is the entire justification; verify it early with a Ruby worker consuming a PHP-produced job and vice versa.
• Deploy-time code skew: forked workers run the code loaded at boot. Every deploy must restart workers; a rolling restart with a drain step is mandatory to avoid executing jobs against stale schemas.
• Redis version and topology: standalone or Sentinel is fine; Redis Cluster is a poor fit for Resque's key layout and tooling. Confirm before assuming cluster support.

Sequencing: capability spike → interoperability proof (if Ruby matters) → driver implementation → supervision and restart automation → observability → first queue in production → expand or retire. Gate each stage on the previous stage's evidence; do not skip the interop proof, since it is the only durable reason to adopt this package.

Operational Impact

Maintenance: Low-velocity upstream. Pin to a tagged release, track the repository for security-relevant commits, and budget for an internal fork. Compare against Laravel's first-party queue stack, which receives framework-version compatibility work for free — every Laravel major upgrade becomes a compatibility question you own here.

Support: No commercial backing; community issue tracker only. Support burden lands on the adopting team. Expect to write your own runbooks, dashboards, and failure-triage documentation. Resque's Ruby tooling (resque-web) is usable against shared Redis and is the strongest operational asset, but it is a separate Ruby runtime to stand up.

Scaling:

• Scale-out is horizontal and simple: add worker processes/hosts, tune concurrency to CPU and memory (fork-per-job means memory is roughly baseline × concurrent children).
• Prioritization is queue-ordering based (a worker polls queues in a fixed order), which is coarser than Laravel's per-queue priority weighting and can starve low-priority queues under sustained load.
• Redis becomes a throughput and availability bottleneck; size for peak enqueue rate and monitor list depth and job latency directly.
• Cold-start/autoscaling is poor: forking workers are long-lived, so Kubernetes HPA on CPU reacts slowly to queue depth. Use queue-depth-based autoscaling or accept static capacity.

Failure modes to instrument and runbook:

• Silent job loss from Redis eviction or restart without persistence — enforce noeviction + AOF/RDB, alert on list depth dropping to zero unexpectedly.
• Orphaned/zombie workers and fork failures under memory pressure — alert on child count and worker heartbeat.
• Stuck jobs with no timeout — Resque has no visibility timeout; implement a per-job watchdog or accept indefinite hangs.
• Duplicate execution (at-least-once) — job handlers must be idempotent; this is a design requirement, not a nice-to-have.
• Deploy skew — jobs failing with class-not-found or signature mismatch after a rename; enforce drain-then-restart.
• Poison payloads — a malformed or malicious job payload can halt a worker; validate and dead-letter into the failed queue with alerting.

Ramp-up: Engineers fluent in Laravel queues face a real relearning cost — different failure semantics, different retry model, different debugging tools. Estimate 2–4 weeks for a small team to reach production confidence, plus ongoing on-call familiarity. The hidden cost is cognitive: two job systems in one codebase invite inconsistency (some jobs retry automatically, some don't), so publish a written policy on which queues use which system and why.

Bottom line for a TPM decision: adopt only if PHP↔Ruby Resque interoperability is a current, funded requirement; otherwise the maintenance, failure-handling gaps, and dual-paradigm overhead outweigh the 8.8 score, and Laravel's native Redis driver with Horizon is the lower-risk default. If adopted, fund the custom driver, supervision, and observability work up front rather than after the first incident.