Redis Transport Laravel Package

Product Decisions This Supports

• Build vs. buy for the event transport layer: v1.0.0 marks the first stable release of the Redis Streams–backed transport for RabbitEvents. If we already run Redis, this is a credible "buy" that avoids operating a separate broker solely to get at-least-once delivery, consumer groups and retries — a real infra-cost decision rather than a library preference.
• Messaging topology / fan-out correctness: Retries, requeues, rabbitevents:retry and failed messages now land on a per-queue direct stream (rabbitevents:queue:{queue}) instead of the shared topic stream. Previously those went back to the shared stream and were visible to every consumer group, i.e. cross-service duplicate work. This is the core product win: per-service retry isolation and predictable blast radius.
• Dead-letter / failure operations as a shippable feature: Failed messages now go to {queue}.failed, so rabbitevents:failed, retry, forget and flush work on Redis. That unlocks real roadmap items — support runbooks, "replay a failed webhook" admin tooling, DLQ dashboards — without us writing bespoke failure storage.
• Reliability commitments we can make to the business: requeue() and reject(requeue: true) now actually redeliver in order (before, messages sat in the Pending Entries List and effectively vanished from view), and a PEL-stuck bug when a read spanned two streams is fixed. These are message-loss/duplicate-delivery class fixes, not polish — they change what SLAs we can honestly promise.
• Platform versioning decision: v1.0.0 requires rabbitevents/foundation ^10.0; RabbitEvents 9 users must stay on 0.0.x. This turns "do we adopt the Redis transport?" into "do we join the RabbitEvents 10 upgrade train?", which is a sequencing call for the platform roadmap.
• Scaling / cost model: Multiple consumer groups can each read the shared topic stream and drain only their own direct stream, which supports horizontal consumer scaling per service without multiplying retry traffic. Relevant to capacity planning and Redis sizing/trimming decisions.

When to Consider This Package

Adopt when:

• We are on (or committing to) RabbitEvents 10 — otherwise this release is simply unavailable and 0.0.x is a dead end.
• We already operate Redis with Streams and want event-driven Laravel services without adding or growing a RabbitMQ footprint.
• We need at-least-once delivery with per-service retries and a manageable failed queue, and we want failed/retry/forget/flush parity with the rest of Laravel's queue tooling.
• We have multiple consumer groups per topic and actually want retries scoped to the queue that failed — the new topology is a strict improvement here.
• Ops can own Redis Streams realities: memory/trimming policy, consumer-group lag monitoring, PEL inspection.

Look elsewhere (or defer) when:

• Delayed retries / backoff are required. Fixed: setDeliveryDelay() no longer throws — but Redis can't delay delivery, so retries now fire immediately and --sleep (default 5) is effectively ignored. Any workflow relying on spacing out retries (third-party APIs, rate-limited downstreams, flaky webhooks) needs application-level backoff or a different transport. This is the single biggest caveat in the release.
• We need broker features Redis Streams doesn't have: priority queues, per-message TTL, rich routing, or mature DLQ inspection tooling.
• We depend on the old semantics where retries were visible to all consumer groups (unlikely to be intentional, but worth confirming no team built on it).
• We can't tolerate the coordination cost of a major-version upgrade across every service, or we're pinned to RabbitEvents 9.
• We need a multi-year-mature dependency; this is a 1.0.0 — semver stability is now promised, but field mileage is thin and the release itself contains two correctness fixes, which is a signal to pilot rather than roll out org-wide.

Migration note for planning: upgrading is not a flag day — entries already in the shared stream keep being delivered while new retries go to direct streams, so mixed-version traffic during rollout is safe. That materially lowers the risk of scheduling the upgrade.

How to Pitch It (Stakeholders)

To executives: This is a stability and cost-efficiency release for our event transport. It makes retries and failures isolated per service instead of leaking to every consumer, gives us a real failed-message queue with standard replay/forget tooling, and fixes two bugs that could silently lose or strand messages — so we can promise tighter delivery guarantees without new infrastructure spend. The trade-off is a coordinated upgrade to RabbitEvents 10 and an honest caveat that Redis can't schedule delayed retries, so retries happen immediately and any backoff must live in our application code.

To engineering: v1.0.0 is the first stable release and requires rabbitevents/foundation ^10.0 (stay on 0.0.x for RabbitEvents 9). Behavioural changes to plan around: each queue now reads the shared topic stream plus its own direct stream rabbitevents:queue:{queue}, and retries/requeues/rabbitevents:retry/failed messages are written to the direct stream rather than the shared one. Failed messages go to {queue}.failed, so rabbitevents:failed, retry, forget and flush now work with Redis. requeue() and reject(requeue: true) genuinely redeliver while preserving order. Two fixes worth noting: delayed retries previously crashed on setDeliveryDelay() — now they retry immediately (Redis can't delay), which removes the --sleep backoff and warrants a retry-storm review; and a Pending Entries List entry could get stuck when a single read returned entries from two streams. Upgrade is rolling-safe: in-flight shared-stream entries still deliver, only new retries use the direct streams.

Recommended next step: pilot on one non-critical service, confirm retry behaviour under induced failure (especially the immediate-retry path and downstream rate limits), validate the {queue}.failed runbook, then schedule the org-wide RabbitEvents 10 upgrade.