Redis Transport Bundle Laravel Package

Product Decisions‌­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­

• Build vs. buy on async transport. If we run Symfony Messenger and want Redis Streams semantics (consumer groups, acks, pending-entry list, replay), the choice is: adopt this transport, adopt Symfony's official symfony/redis-messenger transport (which also targets Redis Streams), write our own ~small transport, or move to RabbitMQ/SQS/Kafka. This package is a candidate in that comparison — not a default.
• Infrastructure consolidation roadmap. Streams let us get durable, replayable, multi-consumer messaging out of the Redis we already operate, without adding a broker to the ops surface. That's a real roadmap lever: "one datastore, no new on-call burden" vs. "broker maturity."
• Feature enablement for event-driven work. Replay, per-consumer-group fan-out, and at-least-once delivery unlock patterns that Laravel/Symfony list-based Redis queues handle poorly (DLQ, reprocessing after a bad deploy, multiple independent consumers on the same event).
• Platform-fit decision (important). This is a Symfony bundle, not a Laravel package. For a Laravel codebase the decision is not "install this" but "do we introduce Symfony Messenger as a component into Laravel?" — a much larger architectural bet. Flag it as out of scope for a pure Laravel queue review. The 1.2.2 release (Symfony 7 support) does not change this: it widens the supported Symfony window, it does not make the bundle Laravel-native.
• Framework-version risk is now lower — but only that risk. 1.2.2 adds Symfony 7 support (#23, contributed by @Prokyonn), so the bundle is current with the framework's supported major rather than trailing it. That removes a "can we even run this on our stack?" blocker from a spike. It does not move the needle on maturity, support, or operational tooling.
• Dependency-risk acceptance. Still 6 stars, 0 dependents, effectively single-maintainer, MIT. A community PR landing is a mildly positive maintenance signal, not a governance upgrade. The realistic framing remains acquiring code we own, not adopting a supported product. That changes the approval bar and the exit plan, not the feature list.
• Narrow niche validation. Low opportunity score reflects a small addressable audience; the decision this informs is mostly "does our specific gap justify being an early adopter?"

When to Consider This Package

Consider it when all of the following hold:

• We are on Symfony 6.x or 7.x with Messenger already in production (not Laravel-only). Symfony 7 is now explicitly supported as of 1.2.2, so an upgrade-blocked stack is no longer a reason to defer a spike.
• We specifically need Redis Streams semantics — consumer groups, acknowledgements, pending/replay — not just "a queue."
• Redis-only infrastructure is a hard constraint (no appetite for RabbitMQ/Kafka ops).
• We have first checked symfony/redis-messenger for feature parity; this bundle only earns a slot if it closes a concrete gap (e.g., multiple transports, retry/DLQ ergonomics, serializer behavior).
• We accept fork-and-own: pin the version, vendor the code if needed (MIT permits it), and assign an owner.

Look elsewhere when:

• Laravel-only stack. Laravel's Redis queue driver + Horizon already covers the 90% case; there is no Messenger integration to hang this on, and 1.2.2 does not change that.
• We need vendor support, SLAs, or a security-response process — nothing in this release suggests one exists.
• Throughput/ordering requirements point at Kafka or a managed broker.
• We need mature observability, DLQ tooling, and dashboards out of the box — a 6-star bundle will not provide them, and 1.2.2 is a compatibility patch, not an operational-tooling release.
• The official Symfony transport already covers our needs (including on Symfony 7): default to the framework-maintained option and skip the third-party dependency entirely.

How to Pitch It (Stakeholders)

To executives: A small, MIT-licensed Symfony add-on that lets our message queue run on Redis Streams instead of adding a new message broker. The upside is infrastructure we already operate and pay for, plus replay/reprocessing capability we don't have today. The newest release (1.2.2) is a compatibility update adding Symfony 7 support — useful because it keeps the option alive on our current framework version, but it is not a maturity milestone. The downside is unchanged: six stars, zero downstream dependents, effectively a single maintainer. Recommendation: timeboxed spike only, no production commitment, and only if the framework's own Redis transport falls short. Cost of trying is low; cost of depending on it is "we now own this code."

To engineering: Treat it as a candidate reference implementation, not a dependency. 1.2.2 only adds Symfony 7 support (a single merged community PR), so it clears the framework-version check and nothing else — no new transport features, no observability, no tooling. First step is still a one-week spike: run it against a real workload on Symfony 7, then diff its capabilities against symfony/redis-messenger. If parity, we use the official transport and drop this. If it solves a specific gap, we fork it, pin it, and add it to the owned-code list with a named maintainer and an exit plan back to the official transport. Do not put it on a critical path without that fork decision made.