- What is yangusik/laravel-balanced-queue used for?
- It is a third-party Laravel queue driver for spreading jobs across a pool of Redis connections or nodes and across partitions such as user groups or tenants. It is aimed at fair job distribution and concurrency control per user or tenant. It replaces the stock redis driver rather than supplementing it, so evaluate whether you need balancing behavior Laravel does not already provide.
- How do I install yangusik/laravel-balanced-queue?
- Install it with Composer using composer require yangusik/laravel-balanced-queue, then configure a queue connection that uses the package driver and point it at your Redis connections or partitions. Because it replaces the stock redis driver, validate the configuration against a staging queue before changing production workers. Also confirm the supported Laravel version matrix in the package composer.json and CI configuration before installing.
- Which Laravel versions does this package support?
- The provided materials do not confirm the exact supported Laravel version matrix, which is a key adoption question for this package. Check composer.json and the CI test matrix for the versions you run, and confirm CI is green against them. Do not assume support for every Laravel release from 5.x through 11.x without verification.
- How does the load balancing algorithm work?
- The package is described as balancing jobs across Redis connections, nodes, and partitions for fair distribution and concurrency control. The provided materials do not specify whether the algorithm is round-robin, random, least-queue-depth, or weighted. Confirm the exact balancing semantics in the documentation and tests before relying on them for fairness guarantees.
- Does it work with Laravel Horizon?
- The provided materials do not confirm whether this driver coexists cleanly with Horizon or requires Horizon to be disabled. Laravel Horizon already covers most multi-node operational needs such as supervision, metrics, and retry or failure visibility. If you already run Horizon, verify compatibility and identify what observability you would lose before adopting this driver.
- Is maxTries reliable with this queue driver?
- Version 1.3.3 fixed attempts incrementing on pop so that maxTries is actually reachable. Before that fix, a poison job could effectively loop indefinitely, consume workers and Redis memory, and leave failed_jobs under-populated. Use 1.3.3 or later and test poison-job behavior and failure dashboards before trusting it in production.
- Does it support afterCommit, job batches, and chains?
- Version 1.3.3 fixed PendingDispatch::afterCommit, which indicates the driver does not transparently inherit every Laravel dispatch lifecycle behavior. Teams relying on afterCommit, dispatchAfterResponse, chained jobs, or batches should assume gaps may exist until proven otherwise. Write conformance tests for those paths against the stock redis driver before migrating.
- What happens when a worker dies mid-job?
- Version 1.3.3 added a reserved payload copy and recovery of expired reservations, because previously a worker dying mid-job could orphan the payload with no recovery path. The fix increases Redis memory usage and raises a duplicate-execution question if recovery reclaims a reservation from a merely slow worker rather than a dead one. Verify that recovery respects retry_after semantics and cannot double-deliver to a live worker.
- Is this package safe for production use?
- The technical risk is high: it is a single-maintainer project with community-contributed fixes, and four correctness bugs, two of them data-integrity class, landed in one patch release. The design requires tracking and re-implementing Laravel RedisJob internals, creating a permanent maintenance tax on Laravel minor releases. Treat patch-level versioning as a poor proxy for risk and require a conformance test suite, a second maintainer, and a clear release cadence before production adoption.
- How does it compare to Laravel's built-in redis driver and Horizon?
- Laravel's built-in redis driver already accepts an array of connections for random balancing, and Horizon covers most multi-node operational needs such as supervision, metrics, and retry or failure UI. This package is a narrow fit only if you specifically need balancing semantics Laravel does not offer, such as weighted or load-aware distribution, and you are prepared to own a fork of framework internals. Otherwise, adopting it is likely a net-negative trade.