Redis Messenger Laravel Package

Product Decisions This Supports

1. Build vs. buy on async infrastructure. This package answers a narrow, recurring PM question: do we stand up a real broker, or do we push queueing onto Redis we already run? It is the "buy" answer for teams already on Symfony Messenger — the transport is maintained upstream, MIT-licensed, and follows Symfony's LTS cadence. The decision it unlocks is not "Symfony vs. Laravel" but "do we pay for RabbitMQ/Kafka operations, or do we amortize the Redis cluster we already fund?"

2. Transport choice as an option, not a commitment. Because Messenger handlers are written against a transport-agnostic interface, this package lets us ship on Redis now and swap to AMQP, SQS, or Doctrine later without rewriting job logic. That is a genuine strategic asset: it defers a hard-to-reverse architecture bet by one or two quarters.

3. Roadmap scoping for async workloads. Redis Streams with consumer groups gives us ack/reject/retry and multiple concurrent consumers, which covers the bulk of our "make this request faster" backlog: webhook fan-out, third-party API calls, report generation, notification bursts. It is the wrong tool for event sourcing, replayable audit logs, or multi-language consumers — so this package effectively draws the boundary line on the roadmap for us.

4. Hybrid / transitional estates. The clearest strategic fit is a Laravel codebase that already pulls Symfony components, or a company running Symfony and Laravel services side by side. One messaging contract across both is worth more than either framework's native default.

5. Operational investment sizing. Adoption implies funding Redis durability (AOF/RDB), stream trimming policy, dead-letter handling, and dashboards. Because this package deliberately ships no Laravel Horizon equivalent, the PM should budget that tooling explicitly rather than assume it arrives for free.

6. Version and platform planning. Symfony 8.x targets PHP ≥ 8.4 and bumps ext-redis/ext-relay minimums. That is a dependency in our PHP upgrade roadmap, not a detail engineering can absorb silently.

When to Consider This Package

Adopt when most of these hold:

• The team has already committed to symfony/messenger — either directly, or via a Laravel app already using Symfony components — and needs a transport that isn't a new piece of infrastructure.
• Redis is already in the stack for cache/sessions, so marginal infrastructure cost is near zero.
• Workloads are high-volume and short-lived (seconds, not hours), where in-memory latency is the point.
• You need consumer-group semantics: multiple workers, explicit ack/reject, retry with backoff, and a failure transport.
• You are migrating between Symfony and Laravel, or operating both, and want one message contract.
• You can accept a wrapper layer: custom Queue::extend adapter, custom worker process wrapping messenger:consume, and custom listeners to restore Laravel's job:failed / job:released events.

Look elsewhere when any of these hold:

• Pure Laravel shop. Laravel's native Redis queue driver plus Horizon already delivers queueing, retries, batching, rate limiting, and a monitoring UI. Adopting this package means rebuilding Horizon by hand — a bad trade unless cross-framework messaging is the actual requirement.
• You need durable, replayable, order-guaranteed event logs. Redis is ephemeral by default and stream trimming (MAXLEN) is a data-loss decision disguised as a config value. Reach for Kafka or RabbitMQ.
• Horizon-class observability is a launch requirement. It will not work out of the box; there is no adapter.
• Redis is not already operated by the team. Adding Redis purely as a broker imports provisioning, failover, backup, and Sentinel/Cluster configuration work that no one has scoped.
• Your team has no Symfony Messenger fluency. Transport, Handler, Envelope, Stamp, and messenger:consume are a real ramp-up, and the failure mode — a worker that silently stops consuming — is expensive to debug without familiarity.
• You are on an old PHP/ext-redis baseline. Version floors move aggressively at the 8.x line.

Due-diligence note for stakeholders: the 217-star count and "0 dependents" figure are artifacts of this being a read-only subtree split of symfony/symfony — issues and PRs live in the monorepo. Do not read low stars as low adoption. Read the release history instead, which is the real signal: continuous patches across the 6.4 LTS, 7.x, and 8.x lines for ack/reject on already-deleted entries, duplicate pending messages under batch handlers, Sentinel SSL/auth forwarding, and ext-redis compatibility churn. The package is actively maintained and the edge cases are non-trivial — both facts belong in the risk register.

How to Pitch It (Stakeholders)

To executives — one paragraph: "We already pay for Redis. This lets us run background jobs on infrastructure we own instead of standing up and staffing a new message broker, and because the job code is written against a transport-neutral interface, we can move to RabbitMQ, SQS, or Kafka later without rewriting it. It is upstream-maintained, MIT-licensed, and ships on a predictable release train, so we are not betting on a hobby project. The trade-off is that it does not come with a monitoring dashboard the way Laravel Horizon does, so roughly the cost of one adapter and one operational setup is the price of entry — versus the recurring cost of a broker plus on-call for a new system."

To engineering — the honest version: "This is a Symfony Messenger Redis transport, not a Laravel queue driver. If we adopt it we own three pieces of glue: a Queue adapter bridging Messenger's transport into Illuminate\Queue, a worker process wrapping messenger:consume in place of queue:work, and event listeners to restore Laravel's job lifecycle events. We also own Redis durability (AOF), a stream retention/trimming policy, and dead-letter handling — none of which are optional if we care about not losing messages. In exchange we get consumer groups, explicit ack/reject, retries with backoff, delayed messages, concurrent consumers, and a transport abstraction that makes our next broker migration a config change rather than a refactor."

The one-line decision framing for the roadmap review: Adopt this only if cross-framework or transport-portable messaging is a stated requirement. If the goal is simply "make background jobs faster in a Laravel app," use Laravel's native Redis queue and Horizon and spend the saved effort on something else.