Beanstalkd Messenger Laravel Package

Product Decisions This Supports

• Build vs. buy for async processing: This is a thin transport adapter, not a queue platform. It informs the decision of whether to standardize on Symfony Messenger as your message bus versus Laravel's native Illuminate\Queue. If you pick Messenger, this package is the cheapest possible way to get Beanstalkd as a transport.
• Broker selection (Beanstalkd vs. Redis vs. SQS vs. RabbitMQ): Supports a deliberate choice of a minimal, single-purpose work queue for fire-and-forget and delayed jobs, where you do not need fanout, routing topologies, or stream replay.
• Polyglot / multi-framework architecture: Meaningful only if your org already runs Symfony services or shares a Beanstalkd cluster across PHP services. A shared broker with one adapter per framework becomes a real architectural option.
• Migration and exit strategy: Useful as a transitional transport — e.g., moving a legacy Beanstalkd-backed worker fleet onto Messenger semantics without a broker migration in the same quarter.
• Scope discipline on queue features: Adopting this forces an explicit decision about what you are giving up — no Horizon, no Laravel failed_jobs table integration, no queue:work event hooks, no dispatch() ergonomics. That is a roadmap-level trade, not a code-level one.
• Ops investment sizing: Beanstalkd is in-memory by default (persistence only via the binlog flag), so this decision drives whether you staff durability/backup work or accept job loss on restart.

Important caveat for a Laravel roadmap: for a conventional Laravel application this is not the right tool. Laravel ships a first-party Beanstalkd driver (via pda/pheanstalk) that plugs into the full queue ecosystem. This package targets Symfony Messenger's transport interface and only becomes relevant if you deliberately run Messenger inside Laravel (or in a sibling Symfony service). Treat "we use Laravel" as a near-disqualifier unless the Messenger decision is already made.

When to Consider This Package

Consider it when:

• You are already committed to Symfony Messenger (standalone in Laravel, or in Symfony services) and just need a transport.
• Beanstalkd is already operated in-house — the marginal infra cost is zero.
• Workloads are modest-throughput, latency-tolerant, and idempotent: emails, thumbnails, webhooks, report generation.
• You want simple delayed jobs, per-job TTR/timeouts, and bury/kick retry semantics without running RabbitMQ or Kafka.
• Licensing/governance matters: MIT, and the package sits under Symfony's stewardship, so the low star count is a discovery signal rather than necessarily an abandonment signal — but verify commit cadence and open-issue response before betting on it.
• You want a broker-agnostic bus so a later swap to SQS/AMQP is a config change, not a rewrite.

Look elsewhere when:

• The app is a standard Laravel product. Use Laravel's native queues; you inherit Horizon (Redis), failed_jobs, retries/backoff config, batching, and dispatch() — none of which this package provides.
• You need durability guarantees for revenue-affecting jobs. Beanstalkd without binlog persistence is a data-loss surface; SQS/RabbitMQ/Redis-with-AOF are safer defaults.
• You need routing, fanout, consumer groups, replay, or ordering guarantees — that is RabbitMQ/Kafka territory.
• You need managed cloud brokerage or a vendor SLA. Nineteen stars implies you are largely your own support tier.
• Your team has no Beanstalkd operational experience; the "simple" broker still needs monitoring, tube hygiene, and stuck-job runbooks.
• You need exactly-once or transactional-outbox semantics — no transport gives you that for free, and this one gives you nothing extra.

Adoption gate: require a spike proving (a) retry/dead-letter behavior on buried jobs, (b) observability via your existing APM, and (c) restart-durability posture — before it appears on a roadmap.

How to Pitch It (Stakeholders)

To executives: This is a small, MIT-licensed connector, not a platform bet. It costs almost nothing to trial and lets us keep our existing message broker instead of procuring a new one. The honest framing: it is a tactical choice that reduces infrastructure spend and vendor lock-in, but it sits in a niche ecosystem with a small community, and the underlying broker is mature-but-quiet. Recommend it as a scoped experiment behind a feature flag, with a named fallback (Laravel's native queues, or SQS), rather than as a multi-year standard.

To engineering: It is a transport adapter for Symfony Messenger — roughly a config-level integration, low code surface, low maintenance burden. The real cost is ecosystem, not code: we lose Laravel's queue tooling (Horizon, failed-job dashboards, dispatch ergonomics) and gain manual ownership of retries, dead-letter handling, and broker durability. If we are not already on Messenger, this package is a solution to a problem we don't have. If we are, it is the least-effort path to a working async pipeline and keeps the broker swappable later.

Recommendation: Explore-and-validate, don't standardize. Highest-value use case is a polyglot org consolidating on an existing Beanstalkd cluster; lowest-value use case is a greenfield Laravel product, where the native queue driver wins on tooling alone.