micro-module/job-queue
A lightweight job queue module for Laravel micro-modules: dispatch and delay background jobs, process them with configurable workers, and handle retries and failures through a simple API that drops into any modular Laravel application.
Architecture fit. Laravel ships a mature, first-party queue subsystem (database, Redis, SQS, Beanstalkd, sync drivers) with workers, retries, backoff, failure handling, batching, and Horizon observability. A third-party package named micro-module/job-queue must therefore justify itself as either (a) a thin abstraction that composes job handling inside a "micro-module" architecture, (b) a replacement driver, or (c) a domain-specific scheduler/dispatcher layered on top of Illuminate\Contracts\Queue. The package name signals the first case: modular, composable queue handling for teams structuring a Laravel app as discrete micro-modules (a modular monolith pattern). If that is the case, its value is organizational—encapsulation and module isolation—not raw throughput. If it merely re-implements laravel's queue primitives, it is redundant and should be rejected. This distinction is the single most important thing to confirm before any effort is spent.
Integration feasibility. Composer-installable with an MIT license, so legal/procurement friction is near zero. The real gates are version constraints: confirm Laravel and PHP version support in composer.json, whether it implements the framework's queue contracts (so it can be swapped behind an interface), and whether it registers a service provider and config publish tag consistent with Laravel conventions. With zero dependents, there is no evidence of it working in a real production install; the integration must be validated by a spike, not by documentation claims.
Technical risk. High, and concentrated in a few areas:
Key questions. What problem does this solve that Laravel's queue does not? Does it implement Illuminate\Contracts\Queue\Factory and ShouldQueue, or fork them? Which drivers does it support, and does it delegate to Redis/database or roll its own? How are retries, failures, and dead-lettering handled? Is there CI, test coverage, static analysis, and a changelog? What is the maintainer's commitment and release cadence (the April 2025 release is a positive but single data point)? Does it interoperate with Horizon, Telescope, and queue:work/queue:listen?
Stack fit. Adopt only if the team is standardizing on a micro-module architecture and needs queue ownership scoped per module—e.g., each module declaring its own jobs, connections, and retry policy without cross-module coupling. If the goal is simply "run background jobs," do not integrate; use Laravel's native queue drivers and move on. There is no throughput, cost, or feature advantage demonstrated here to displace the framework default.
Migration path. Treat this as an evaluation, not a migration. Sequence:
JobDispatcher interface so the underlying implementation (package vs. native) is swappable and the blast radius of abandonment is contained.Compatibility. Verify composer.json constraints against the target Laravel/PHP versions, confirm no conflict with laravel/framework or laravel/horizon, and check that published config does not override global queue settings. Because dependents are zero, expect to be the first real integration and budget for discovering rough edges.
Sequencing. Do the source review before committing engineering time; do the spike before promising the architecture team anything; do the interface abstraction before any production use. Do not sequence this ahead of native queue adoption—run them in parallel only if the modular-encapsulation benefit is a stated requirement.
Maintenance. With one maintainer and no downstream users, the realistic assumption is that your team owns this code the day it ships. Budget for fork-and-maintain: ~0.1–0.25 FTE ongoing for security patches and Laravel major-version upgrades, plus incident time. MIT licensing makes forking legal; the cost is cognitive, not legal.
Support. No community, no Stack Overflow corpus, no issue-tracker history to mine. Internal documentation and a named owner are mandatory. Escalation path is "read the source."
Scaling. Unproven at any load. Before relying on it, load-test against the native driver on the same infrastructure and compare throughput, latency, memory per worker, and backpressure behavior. If it delegates to Redis or the database, scaling characteristics follow the underlying store and risk is lower; if it implements its own broker or polling loop, treat scaling as unknown and potentially poor.
Failure modes. The failure surface to enumerate: lost jobs on worker crash, duplicate execution under retry, stuck jobs with no visibility timeout, unbounded retry storms, silent failures with no dead-letter queue, and missing observability (no Horizon/Telescope integration). Each of these is a customer-visible incident class. Compare each against the native driver's documented behavior and require parity before production.
Ramp-up. The team already knows Laravel queues; the incremental learning cost is the package's module conventions plus its divergence from core semantics—likely 1–2 days per engineer, plus the interface abstraction. The larger cost is organizational: explaining to the team why a zero-adoption package sits on the critical path.
TPM recommendation. Do not adopt on the basis of the current evidence. Fund a two-day spike only if the micro-module encapsulation is a genuine architectural requirement; otherwise standardize on Laravel's native queue and revisit if the package gains dependents, contributors, and documented production use. Keep the option open behind an interface, cap the investment, and set an explicit review trigger (e.g., ≥3 dependents or a second maintainer) before reconsidering.
How can I help you explore Laravel packages today?