Beanstalk Queue Driver Bundle Laravel Package

Product Decisions This Supports

• Queue backend standardization (build vs. buy vs. adopt). This package is a decision input for "what broker runs our async work?" It makes Beanstalkd a low-glue option for Symfony services — not Laravel. Where the stack is Symfony, it lets us evaluate Beanstalkd's semantics (priorities, delay-until, TTR) against Redis/SQS without writing custom wiring; where the stack is Laravel, the answer is already "use the first-party beanstalkd driver" and this package is not in the decision set at all.
• Async feature roadmap. Supports scoping of background work — transactional email, exports, webhooks, media processing, notifications — where latency-sensitivity and priority ordering are product requirements. Beanstalkd's priority/delay/TTR model maps directly to retry and backoff policy, so adopting it is really a statement about how much retry sophistication the roadmap needs.
• Infrastructure cost/ops posture. Beanstalkd is one small daemon plus a binlog. That supports a decision to reduce managed-queue spend and avoid operating Redis Cluster or SQS IAM plumbing at modest throughput — a real option for early-stage or internal-tooling products.
• Explicit non-fits. This does not support scheduled/cron recurrence, fan-out pub/sub, event streaming, or long-running jobs beyond TTR without heartbeat design. Those requirements push the decision toward SQS + Redis/Horizon or a stream platform, and should be captured as roadmap constraints now, not discovered later.
• Architecture reversibility as a first-class decision. With ~1 star, 0 dependents, and a 0.005 score, the package is a reference implementation, not a strategic dependency. The most defensible product decision it informs is: put queue usage behind an internal interface so the broker stays swappable and the framework choice stops being a lock-in.
• Framework-fit validation. The artifact is a Symfony bundle; the brief says Laravel. That mismatch is itself a decision to resolve before any roadmap item assumes this dependency exists.

When to Consider This Package

Consider it when:

• The application is Symfony — not Laravel — and the team wants Beanstalkd wired into the service container and queue abstractions declaratively, rather than hand-rolling a pheanstalk integration.
• Beanstalkd's specific semantics (priority, delay, TTR, bury/kick) are actual product requirements and you want them exposed via config instead of bespoke code.
• Throughput is modest, service count is small, and operational simplicity beats ceiling and HA.
• You are prototyping to validate Beanstalkd as a backend before committing to a bespoke implementation — a spike, not a launch.

Look elsewhere when:

• You are on Laravel. Use the native beanstalkd driver (QUEUE_CONNECTION=beanstalkd, pda/pheanstalk, config/queue.php). This bundle has no service provider, no Laravel hooks, and will not register itself; wiring it in means hand-writing a Connector/Queue implementation to reach a less-supported code path.
• You need production-grade support, a security response process, or a roadmap you can influence. Single maintainer, no community, no dependents — bus factor of one. Treat as unsupported.
• You need managed infrastructure, HA, or multi-AZ durability. Beanstalkd has no native clustering or replication; SQS, RabbitMQ/CloudAMQP, or Redis with persistence fit better.
• The workload is high-throughput, long-running, scheduled, or pub/sub. Wrong tool; use SQS, a managed broker, or a stream platform.
• You are unwilling to own the code. Adopting unsupported glue means you fork and patch it; if that isn't budgeted, don't start.

Adoption guardrails if you proceed: pin the version, wrap the driver behind an internal JobQueue interface, run dependency-health review on a quarterly cadence, and pre-agree a fallback path (native driver or Redis) with a written decision memo.

How to Pitch It (Stakeholders)

To executives (30-second version): This is a small, MIT-licensed integration library that lets PHP applications use Beanstalkd — a lightweight, cheap-to-run job queue — for background work like emails, exports, and webhooks. It is a low-cost path to reliable async processing without buying managed queue capacity, and Beanstalkd itself is operationally trivial. The catch is decisive: the artifact is a Symfony bundle while our stated stack is Laravel, and it is an unsupported, single-maintainer project with effectively zero adoption. Recommendation: do not adopt it as a dependency. On Laravel we use the native Beanstalkd driver; on any Symfony service it is a prototype enabler and a reference for an internal wrapper. Validate demand first, then either fork it deliberately or standardize on a first-party driver.

To engineering: It's a thin Symfony bundle over Beanstalkd — dependency-injection glue, not a driver. On Laravel it is a non-starter: we already have beanstalkd behind the Queue contract, and integrating this would mean running a parallel Symfony container or re-implementing a connector to consume a package that adds nothing. On Symfony it saves a few days of glue at the cost of a bus-factor-of-one dependency with unverified PHP/Symfony version pins and unknown coverage of Beanstalkd protocol edge cases (reserve timeouts, TTR, bury/kick). Either way, the requirement stands: the integration lives behind an internal interface so the broker choice stays reversible and migration doesn't mean rewriting call sites. Concrete next step is a timeboxed spike — read composer.json constraints, diff the job envelope against the native driver, and only prototype if a real gap is demonstrated.

To finance/ops: Beanstalkd is one small daemon and a binlog — operationally trivial and materially cheaper than managed queues at our volume. The trade-off is durability and HA: no replication, so it is not a fit for anything we cannot afford to replay from source. Note the maintenance line item: because this specific wrapper is unsupported, adopting it means we absorb upkeep the moment upstream stalls. That cost belongs in the proposal, not in a surprise mid-quarter.