Messenger Worker Registry Laravel Package

Product Decisions This Supports

• Queue observability investment: Informs whether to build, buy, or defer a "worker liveness" capability this quarter. The package is a reference implementation of a Symfony Messenger worker registry — heartbeats plus metadata (name, PID, host, status) about live consumers — so it is a concrete input to the "do we need a worker dashboard?" decision.
• Build vs. buy vs. fork: At 2 stars and 0 dependents, this is source material, not a vendor. Reading a few hundred lines gives a credible estimate of what a minimal in-house registry costs us, and a realistic floor for the effort.
• Deployment and scaling strategy: A registry of consumers (queue, host, version) supports decisions on horizontal scaling, blue/green worker rollouts, and graceful shutdown orchestration — particularly for preventing "scaled up, but old pods are zombies" after a Kubernetes restart.
• Incident-response design: Enables detection of zombie or stuck consumers, which shapes on-call runbooks and alert thresholds for async workloads.
• Use cases to validate: Consumer health dashboards, orphaned worker cleanup, per-queue capacity planning, canary worker verification after deploy, and graceful-restart coordination via SIGTERM handlers.
• Stack-fit check for Laravel teams: Laravel Horizon already occupies much of this space; adopting a Symfony-centric registry is a platform decision, not just a feature decision. This package forces that conversation early, which is itself useful.

When to Consider This Package

Consider it when:

• You run Symfony Messenger with multiple long-running messenger:consume processes and have no per-worker visibility today.
• You want a lightweight heartbeat/registry without standing up Datadog, Prometheus exporters, or Sentry cron monitoring.
• Your team can own and vendor PHP code, including hardening work: heartbeat TTLs, stale-entry eviction, multi-host locking, and fail-open behavior if the registry backend is unavailable.
• You primarily need a pattern to copy rather than a dependency to install — the design (register workers on start, deregister on WorkerRunningEvent/SIGTERM, expose liveness) is the real deliverable.
• You already operate a hybrid Symfony/Laravel estate and Symfony Messenger is a committed part of the architecture.

Look elsewhere when:

• You need production SLAs, security review, or maintainer support. With 2 stars and 0 dependents there is no ecosystem and no maintainer signal — we become the maintainer.
• You need out-of-box metrics, tracing, or alerting. Use Prometheus with Messenger middleware, Sentry cron checks, or a managed APM instead.
• You are Laravel-native — Horizon or Laravel-first tooling fits better; Laravel queue workers do not emit Symfony Messenger lifecycle events, so there is no integration point without a custom bridge.
• You operate multi-tenant at scale and need strict semver and backward-compatibility guarantees.
• You cannot absorb Symfony Messenger internals ramp-up (worker events, transports, middleware) on top of Laravel queue operations — a niche combination for most Laravel teams.

How to Pitch It (Stakeholders)

To executives: An MIT-licensed, near-zero-cost starting point for answering "which background workers are alive right now?" It is early-stage (2 stars, no dependents), so we should treat it as a timeboxed spike or reference design, not a load-bearing dependency. The upside is operational visibility into async processing — fewer silent failures, faster incident triage, better-informed scaling and restart decisions — at roughly a few engineering days of evaluation cost. The downside risk is bounded: worst case we copy the pattern into an in-house utility we control.

To engineering: It provides a registry of running Messenger consumers with minimal code and no heavy infrastructure. Expect to fork and harden it: heartbeat expiry, stale-entry cleanup, multi-host coordination, TTL semantics, and integration with existing monitoring. Note the stack caveat up front — this targets Symfony Messenger, so in a vanilla Laravel app it only applies via a standalone Symfony worker process or a custom bridge; Horizon is the native alternative. Recommended path: a 1–2 day evaluation against a ~200-line in-house equivalent and against existing tooling (APM, Horizon, Symfony tooling), run as a spike in a non-production worker, wrapped behind an internal WorkerRegistry interface so application code never depends on Symfony classes directly. Adopt only if it clearly saves effort and we accept ongoing ownership and compatibility work for future Symfony/Laravel upgrades.