Pheanstalk Bundle Laravel Package

Technical Evaluation

Architecture fit

• leezy/pheanstalk-bundle is a Symfony bundle, not a Laravel package. It wires pda/pheanstalk — the PHP client for beanstalkd — into Symfony's DI container, config tree, and console. Laravel has no bundle concept, so there is no composer require path where this "just works" as a service provider would.
• The decisive TPM finding: Laravel already ships a first-class beanstalkd queue driver on top of the same pda/pheanstalk client. For a Laravel codebase, this bundle contributes nothing the framework doesn't already provide — no facade, no queue connector, no job-dispatch integration, no Laravel-side configuration.
• The real dependency in any evaluation is pda/pheanstalk plus a beanstalkd cluster, not this package. The bundle matters only if the estate contains Symfony services, or if we deliberately standardize on a shared beanstalkd transport across polyglot PHP services.
• Beanstalkd itself is a deliberately minimal work queue (tubes, priority, TTR, delay, bury/release). Strong fit for short-lived, idempotent, latency-sensitive jobs; poor fit for durability guarantees, complex routing, or fan-out semantics. Its native primitives map cleanly onto product asks — "retry in 5 minutes," "password resets jump the queue," "park failed jobs for inspection."

Integration feasibility

• Low effort in Symfony (require, register in bundles.php, add a leezy_pheanstalk config block, inject the connection service). High friction in Laravel: we would either use the native driver and skip the package, or build a bridge wrapping bundle services for zero incremental capability. The latter is pure overhead.
• No Laravel-native API surface: no service provider, no publishable config, no facade, no queue connector. Any Laravel adoption is effectively a fork or re-implementation.
• Maintenance signal is weak: ~124 stars, 0 dependents, single maintainer. For a package positioned as infrastructure glue, near-zero downstream usage means near-zero community testing.
• PHP/Symfony version drift is the most likely hard blocker. Bundle structure and DI APIs move across Symfony majors; the constraint set may pin us out of our target PHP runtime.

Technical risk

• Abandonment (high): low-dependency bundle glue rarely survives framework majors. Mitigation is to own the glue — which argues for not adopting the bundle at all.
• False dependency (medium): adopting this in a Laravel context duplicates framework functionality. That is the worst category of technical debt: a liability that buys nothing.
• Durability (medium, transport-level): beanstalkd is in-memory by default. Without the binlog enabled, a restart or host loss silently discards queued jobs. The bundle can obscure this — teams may assume it provides resilience it does not.
• Abstraction leakage (low-medium): TTR, bury/release, priority 0–2³¹, and tube isolation leak into application code. Neither the bundle nor Laravel's driver fully normalizes them.

Key questions

1. Is the target application Laravel, Symfony, or both? If Laravel-only, this package should be rejected on principle — use pda/pheanstalk through the native driver.
2. What is the job profile: latency-sensitive and short-lived (strong fit) or durable, retry-heavy, long-running (poor fit)?
3. Can we accept at-most-once delivery across broker restarts, or do we require binlog-backed persistence or a different broker?
4. What are the last commit/release dates and the supported Symfony/PHP matrix? Is there a maintained fork?
5. Who operates the beanstalkd cluster, and is there a managed offering in our cloud, or is this self-hosted with on-call implications?
6. For polyglot estates, is a shared beanstalkd transport a real requirement or an artifact of one Symfony service we could isolate?

Integration Approach

Stack fit

• Laravel-first: do not adopt this bundle. Use Laravel's beanstalkd queue driver (QUEUE_CONNECTION=beanstalkd) with pda/pheanstalk in composer.json. We get dispatch(), Queue::push, failed-job handling, and tube configuration — none of which the bundle supplies. Note Horizon is Redis-only, so monitoring must come from beanstalkd's own stats.
• Symfony-first: the bundle is the idiomatic choice, contingent on version constraints. Register in bundles.php, configure host/port/tube defaults, inject the connection service into consumers.
• Polyglot estate: standardize on the transport contract — tube naming, priority bands, TTR ceilings, idempotency keys, payload envelope — rather than on the bundle. Each framework uses its own idiomatic client against that contract.

Migration path

1. Discovery (1 week): inventory existing queue usage, confirm the framework mix, check whether any Symfony service already depends on this bundle.
2. Spike (1–2 weeks): stand up a beanstalkd container; run a representative job through the Laravel native driver and (if Symfony is in scope) the bundle. Measure dispatch latency, TTR behavior under slow jobs, and restart behavior with and without binlog.
3. Decision gate: if Laravel-only, formally reject the bundle, record the rationale, and proceed with the native driver.
4. Pilot (2–4 weeks): move one non-critical, idempotent job class to beanstalkd. Leave all other jobs on the existing driver (database/Redis/SQS).
5. Expand: migrate job classes in risk-tiered batches with per-class rollback via config flag, not code revert.

Compatibility

• Verify pda/pheanstalk against our PHP runtime — historically the client lags on PHP majors.
• Verify the bundle's Symfony constraint band against our Symfony version (or confirm non-applicability under Laravel).
• Confirm Composer resolution does not force a downgrade of a shared dependency; common with older bundle glue.
• Pin the beanstalkd server image explicitly — version affects stats-job, pause-tube, and binlog behavior.
• If a tube is shared across Symfony and Laravel producers, agree the payload envelope explicitly: Laravel wraps jobs in its own JSON structure, raw Pheanstalk payloads do not.

Sequencing

• Transport and cluster provisioning before application code changes.
• Observability (stats exporter, queue-depth and bury-rate alerts) before the pilot, not after.
• Idempotency retrofit on target job classes before cutover — beanstalkd can redeliver.
• Rollback path validated before each migration batch.

Operational Impact

Maintenance

• Bundle maintenance is a net negative for a Laravel team. We would own glue code for a package with 0 dependents and unknown cadence, while the framework's native driver is maintained by the Laravel core team. This is the dominant operational argument against adoption.
• Symfony teams inherit normal bundle maintenance: track Symfony majors, watch for the maintainer going quiet, and be prepared to vendor the bundle if it stalls. At roughly ~1k LOC of glue, forking is feasible — but it is a real, recurring cost.
• Transport maintenance is the larger ongoing item: server upgrades, binlog retention tuning, disk sizing for the binlog, and tube hygiene (orphaned tubes accumulate silently).

Support

• No commercial support behind the bundle; escalation is a fork. Acceptable for internal tooling, questionable for revenue-path work.
• Beanstalkd support is community-only — operationally, our team is the vendor.
• Hiring/knowledge: beanstalkd's protocol is simple enough that ramp-up is measured in days for a competent PHP engineer, but operating it well (persistence, monitoring, backlog recovery) is specialized knowledge held by few. Budget for one named owner rather than relying on team-wide familiarity.

Scaling

• Vertical scaling is the primary axis: beanstalkd is single-threaded per instance and memory-resident. Beyond a certain queue depth or throughput, the answer is sharding by tube across instances, which pushes routing logic into application code.
• Worker concurrency is cheap to add; broker capacity is not. Model expected peak job volume and p99 payload size before committing — the binlog disk requirement grows with both.
• If the roadmap anticipates fan-out, consumer groups, or replay, this is the wrong broker and the decision should be made now, not after adoption.

Failure modes

• Broker restart without binlog: unprocessed jobs are lost. Mitigation is binlog enablement plus accepting degraded throughput, or restricting beanstalkd to jobs that are safe to lose.
• TTR expiry under slow jobs: jobs are re-queued and reprocessed, causing duplicate side effects. Mitigation is idempotency keys on every consumer plus TTR tuning per job class.
• Unbounded bury pile: failed jobs accumulate unnoticed. Mitigation is a bury-rate alert and a documented inspection/triage runbook.
• Silent producer failure: the queue accepts writes but no worker drains it. Mitigation is end-to-end synthetic job monitoring, not just broker-up checks.
• Single-maintainer abandonment: composer constraints break on the next Symfony/PHP upgrade. Mitigation is either not adopting the bundle or vendoring it with a named owner.

Ramp-up

• Week 1: transport contract documented (tube names, priority bands, TTR ceilings, idempotency requirements, payload envelope); beanstalkd provisioned with binlog and stats exporter.
• Week 2: one engineer completes the spike, publishes findings, and the decision gate is recorded — adopt for Symfony, reject for Laravel, or standardize on the transport only.
• Weeks 3–6: pilot one job class, build the triage runbook, wire alerts, rehearse rollback.
• Ongoing: single named owner for the queue platform. If no one will own it, that is itself the answer — use a managed broker and revisit later.