Zmq Laravel Package

Product Decisions This Supports

• Build vs. buy for inter-service messaging. This is not a Laravel feature package; it is a low-level transport binding. The decision it informs is whether to introduce ZeroMQ as your internal messaging primitive instead of Redis pub/sub, SQS, RabbitMQ, or Kafka. That is an architecture decision with a decade-long tail, so it belongs on a roadmap review, not a sprint backlog.
• Latency/throughput-driven feature bets. If a roadmap item depends on high-volume, low-latency fan-out — live telemetry ingestion, market/price tick distribution, real-time scoring calls into a Python/Go/C++ model service — ZeroMQ's PUB/SUB and PUSH/PULL patterns are the right shape, and this binding is the cheapest way to reach them from PHP.
• Offloading hot paths out of PHP. The most defensible use case: keep Laravel as the control plane (API, auth, billing, admin) and push the high-frequency message path into a small long-running ReactPHP daemon using this package. That is a "where does the workload live" decision, and it changes your hosting, observability, and on-call story.
• Interop with existing non-PHP infrastructure. If your org already runs ZeroMQ (common around ML, trading, embedded, or legacy C++ systems), this package lets a PHP service participate without forcing a rewrite of the other side. That is a genuine integration-cost saving.
• Defer / deprioritize decisions. Given 0 dependents, a last release in May 2018, and a low opportunity score, the practical PM output here is usually a negative decision record: "we evaluated ZeroMQ for PHP, rejected it for now, and will use Laravel queues + Redis/RabbitMQ." Writing that down prevents the same evaluation from consuming engineering time again next quarter.
• Not supported: anything Laravel-native. There is no service provider, no queue driver, no facade, no Octane/Swoole integration. A PM should not scope this as "add a package"; it is "stand up and operate a daemon."

When to Consider This Package

Adopt only when all of these hold:

• You already run ReactPHP event loops in production and have engineers who understand non-blocking PHP. This package is a binding, not a framework — it hands you sockets and expects you to own the loop.
• You need ZeroMQ semantics specifically (PUB/SUB fan-out, PUSH/PULL work distribution, DEALER/ROUTER request-reply, reconnect handling, no broker to operate). If you just need async jobs, Laravel's queue system already solves it.
• You control the runtime: you can install libzmq and the ext-zmq C extension in your images. This immediately rules out shared hosting and complicates serverless — it is a Docker-image and CI-pipeline cost, budget it explicitly.
• The latency argument is quantified. If you cannot show that a Redis or RabbitMQ round-trip is measurably too slow for the use case, ZeroMQ buys you operational complexity for nothing.
• You are prepared to own the code path: pin the version, vendor or fork it, and wrap it behind an internal interface so you can swap transports later.

Look elsewhere when:

• PHP version risk is unacceptable. Last release 2018 means no demonstrated PHP 8.x support and no maintenance against changes in ext-zmq. Verify against your target runtime before committing — assume you may be the maintainer.
• You need ecosystem validation or vendor support. 0 dependents and 247 stars is effectively no community. There is no one to escalate to, no security patch stream, and hiring for it is not a signal anyone will recognize.
• You want async PHP generally. Laravel Octane, Swoole, RoadRunner, or Symfony Messenger give you long-running workers with actual maintenance and Laravel integration.
• You need brokered messaging. Durable queues, retries, dead-lettering, backpressure, and delivery guarantees are things ZeroMQ deliberately does not provide. Laravel queues + Redis/SQS, RabbitMQ, Kafka, or NATS are the correct answers.
• You need WebSockets or real-time client push. Laravel Reverb or a managed Pusher-style service is the product-shaped answer; this is a server-to-server transport.

How to Pitch It (Stakeholders)

To executives: Treat this as a narrow infrastructure lever, not a platform bet. It is MIT-licensed and free, but the real cost is ownership: a single-maintainer package last released in 2018, no dependents, and a native C extension in our deployment images. Recommend we do not standardize on it. If a specific high-throughput integration requires ZeroMQ, we approve it as a scoped, time-boxed spike with an exit plan — one daemon, one interface boundary, no propagation into the Laravel application core.

To engineering: This is ext-zmq wrapped in ReactPHP promises — you get sockets bound to an event loop and nothing else. You will own reconnect logic, error handling, message framing, backpressure, process supervision (Supervisor or systemd), health checks, and graceful restarts. It does not plug into Laravel's queue, container, or Octane lifecycle; it runs as a separate artisan daemon. Before adopting, we want: (1) confirmation it runs on our PHP version, (2) a benchmark showing it beats a Redis/RabbitMQ baseline on the actual workload, (3) the transport hidden behind an internal interface so it is replaceable, and (4) a named owner. Absent those, we use Laravel queues and Reverb and revisit only if the latency numbers change the product.