Scheduler Queues Laravel Package

Product Decisions This Supports

• Build vs. buy for background-job plumbing. The package bundles the unglamorous-but-essential layer every queue-heavy Laravel product eventually hand-rolls: idempotency guards, distributed locks, retry/backoff policy, failure capture, and monitoring hooks. A PM can frame adoption as "buy the convention layer, keep building the domain jobs" — a decision that typically saves 2–6 sprint-weeks of senior-engineer time versus in-house scaffolding.
• Roadmap sequencing for reliability work. Because it codifies graceful-deployment behavior (draining/restarting workers around releases, preventing duplicate execution during deploys), it gives you a concrete, shippable answer to the recurring "we lost/duplicated jobs during the last deploy" incident class. That converts a vague reliability epic into a scoped dependency upgrade.
• Feature feasibility for anything with side effects on a schedule. Billing retries, nightly reconciliation, notification fan-out, webhook delivery, report generation, and data syncs all need exactly-once-ish semantics. If the roadmap includes any of these, this package's idempotency + lock policy is directly enabling, not incidental.
• Incident-response and on-call maturity. Built-in failure handling and monitoring conventions reduce mean-time-to-detect for silent job failures — a measurable ops-cost lever rather than a pure engineering preference.
• Standardization across teams/modules. As a "module" in the Liberu ecosystem, it implies shared conventions rather than per-team snowflakes. That's a platform-consistency decision: fewer bespoke job base classes, easier code review, and onboarding that doesn't require tribal knowledge about which queue wrapper to use.

When to Consider This Package

Adopt when most of the following hold:

• You are on Laravel with a real queue workload (Redis/SQS/database driver) where duplicate executions or lost scheduled tasks have user-visible or financial consequences.
• You currently have bespoke, inconsistent job conventions — multiple base job classes, ad-hoc Cache::lock calls, inconsistent retry counts — and want one policy surface.
• You ship frequently enough that deploys overlap with in-flight jobs, and you've either had incidents from it or are pre-empting them.
• You are already inside or comfortable with the Liberu module ecosystem, so the package's conventions match your module loader and service-provider patterns.
• You value convention over configuration and are willing to accept the package's opinions rather than fine-tune every knob.

Look elsewhere or defer when:

• Adoption risk dominates. Zero stars, zero dependents, and a single-vendor release history mean effectively no community validation. Treat the 2026-10-26 release date as a maturity signal to verify, not a guarantee.
• You need audited provenance. If your org requires SOC2-style dependency review, a package with no downstream users will stall in procurement; you may need to vendor/fork it with an internal owner.
• Your queue layer is trivial (a handful of jobs, low volume, no financial side effects) — native Laravel ShouldBeUnique, WithoutOverlapping, and queue:restart cover most of the value at zero dependency cost.
• You need managed visibility. If the priority is a dashboard/SLO view rather than conventions, pair the package with Laravel Horizon or a hosted queue observability tool instead of relying on this alone.
• You're not on Laravel or you've abstracted your queue behind a non-Laravel worker — the value proposition collapses.

PM diligence checklist before committing: pin the version, read the failure/lock semantics for edge cases (lock TTL vs. long-running jobs, poison-message handling, clock skew in idempotency keys), confirm who owns the fork if upstream goes quiet, and require a spike on a non-critical queue before rollout.

How to Pitch It (Stakeholders)

To executives (one paragraph): This is a small, MIT-licensed Laravel module that standardizes how our background jobs behave — preventing duplicate charges and duplicate emails, making sure scheduled work still runs correctly when we deploy, and giving us a consistent way to see and retry failures. It replaces the ad-hoc safety code our engineers currently write per job, which is where reliability bugs hide. Cost is low and reversible; the main caveat is that it's a young package with no external adoption yet, so we'd validate it on a non-critical queue first and be prepared to maintain a fork.

To engineering (one paragraph): Adopt it as the shared policy layer for scheduling and queues: idempotent job handling, distributed locks with sensible defaults, standardized retry/backoff and failure capture, monitoring conventions, and deploy-safe worker lifecycle. The pitch is deleting duplicated base classes and ad-hoc Cache::lock/ShouldBeUnique logic in favor of one reviewed convention. Note it's a 0-star, single-maintainer module — we pin the version, add it behind our own thin interface where practical, and own the fork path. Spike it against one real queue (e.g., webhook delivery) before broad rollout, and measure duplicate executions and failed-job detection time as the two success metrics.

Stakeholder framing by role: Finance/Ops care about duplicate side effects (billing, notifications); SRE cares about deploy-time job loss and MTTR; Engineering leadership cares about removing bespoke scaffolding. Everyone cares that the exit cost is low: it's a convention layer, not a data-store, so backing it out is a refactor rather than a migration.