Redis Transport Laravel Package

Technical Evaluation

Architecture fit

• This is the Redis Streams transport for RabbitEvents, now pinned to rabbitevents/foundation ^10.0. It lets a Laravel service keep the RabbitEvents producer/listener API and consumer-group model while swapping AMQP for Redis Streams — attractive where Redis is already operated for cache/queue/session and a RabbitMQ cluster is not.
• The v1.0.0 topology change is architecturally significant: each queue now reads the shared topic stream (fan-out for broadcast events) plus its own direct stream rabbitevents:queue:{queue} (retries, requeues, rabbitevents:retry, failed messages). Previously these went to the shared stream and were re-delivered to every consumer group — a fan-out amplification bug, not just an inconvenience.
• {queue}.failed via makeFailedQueue() makes the failed-message lifecycle (rabbitevents:failed, retry, forget, flush) functional on Redis. This closes the gap that most likely blocked production adoption of the 0.0.x line.

Integration feasibility

• Composer constraint is a hard pairing: this package 1.0.0 ⇒ foundation ^10.0 ⇒ RabbitEvents 10. Applications must upgrade RabbitEvents and this package in the same change; staying on RabbitEvents 9 means staying on 0.0.x.
• No data migration: entries already in the shared stream continue to be delivered; only new retries route to direct streams. That makes the upgrade deployable without a drain, at the cost of a mixed-topology window.
• Rollback is asymmetric and needs to be validated: direct-stream entries written by 1.0.0 are presumably invisible to 0.0.x consumers. Treat rollback as "drain first," not "revert the tag."

Technical risk

• Silent retry-semantics change. --sleep (default 5s) is now ignored because Redis cannot delay delivery; retries fire immediately. Any team relying on the default backoff for downstream protection loses it without an error.
• Redelivery becomes visible. PEL entries that previously vanished after requeue()/reject(requeue: true) now come back, in order. If consumers were implicitly at-most-once after requeue, expect duplicate side effects.
• New operational surface. Two additional key families per queue (rabbitevents:queue:{queue}, {queue}.failed) with no stated trimming policy.
• Two moving parts at once: 0.0.x → 1.0.0 plus a major foundation bump. The PEL two-stream fix is a behavior fix, but it lands in the same release as the topology change, which complicates attribution during incident triage.

Key questions

• What is the intended retry cap and compensating backoff now that --sleep is a no-op — is a circuit breaker or delayed-retry strategy on the roadmap?
• Are consumers idempotent, and can we prove it before rollout?
• What is the trim/retention policy for the new streams, and who owns Redis memory budget?
• Does the dual-stream XREADGROUP work under Redis Cluster (key-slot co-location / hash tags), and on managed Redis (ElastiCache/Memorystore) with ACL key patterns?
• What are the supported PHP/Laravel and Redis minimum versions for 1.0.0? Not stated in the notes.
• What replaces RabbitMQ management-UI visibility for queue depth, PEL backlog, and failed counts?

Integration Approach

Stack fit

• Laravel + RabbitEvents 10 + Redis Streams (Redis ≥5, practically 6.2+ for reclaim semantics). Where Redis is already in the stack, this removes a broker from the critical path; where RabbitMQ is already operated and trusted, the value is narrower and mostly about the fixed failed-message lifecycle.

Migration path

• Single coordinated bump: RabbitEvents 10 + rabbitevents/foundation ^10.0 + this package 1.0.0. Do not split across deploys.
• No message migration required. Confirm by inspecting the shared stream before/after: pre-existing retries continue to fan out to all groups; new ones do not. Document that consumers may see legacy fan-out retries for a short window.
• Establish rollback criteria up front (error rate, duplicate-processing rate, failed-queue depth) and a drain procedure, since reverting the package does not revert the topology.

Compatibility

• Verify PHP/Laravel support matrix and Redis provider constraints before committing.
• Check instrumentation: any APM/tracing or health checks that assume AMQP queue names or the RabbitMQ management API need remapping to stream/group names.
• --sleep acceptance in config must be treated as deprecated-in-effect; keep the config key but stop relying on it, or fail loudly at boot if a non-zero sleep is configured.

Sequencing

1. Update runbooks, dashboards, and alerts for {queue}.failed and PEL backlog before the upgrade — this is the new failure surface.
2. Staging pilot on one non-critical consumer group with fault injection: kill a consumer mid-processing, force retry/requeue, confirm PEL reclaim and ordered redelivery.
3. Production canary on one low-volume queue, watch duplicate-handling and failed depth for a full business cycle.
4. Roll out per service; leave the shared-stream legacy path untouched until the fan-out tail is drained.
5. Only then decommission any AMQP parallel-run infrastructure.

Operational Impact

Maintenance

• Two packages to track in lockstep (foundation major + this major); version skew is the primary long-term maintenance hazard.
• Redis now owns more data: define trim policy (MAXLEN/XTRIM) and memory alerts per key family, otherwise the failed queues become an unbounded growth path.
• Net reduction in infrastructure surface if AMQP is retired; net increase in Redis responsibility.

Support

• Support tooling must be rewritten: rabbitevents:failed, retry, forget, flush now work on Redis, but there is no equivalent of the RabbitMQ management UI. On-call needs XINFO GROUPS, XPENDING, XCLAIM, XLEN fluency or an internal wrapper CLI.
• Duplicate-processing reports are the most likely new ticket category; publish an idempotency checklist for service teams.

Scaling

• Per-queue direct streams remove cross-group retry fan-out — a genuine scalability improvement: one failing consumer no longer multiplies work across every group.
• Immediate retries remove the only built-in throttle in front of downstream services. During a downstream incident this converts a slow degradation into a load spike; a retry cap plus breaker is effectively mandatory at scale.

Failure modes

• Retry storm / hot loop with no backoff (highest-likelihood new incident).
• Duplicate delivery on requeue and PEL reclaim — at-least-once is now observable; idempotency gaps surface as data defects, not errors.
• Failed-queue accumulation going unnoticed without explicit alerting on {queue}.failed.
• Stuck PEL entries if consumer death plus two-stream reads interact badly (the fixed bug's neighborhood — retest, don't assume).
• Mixed-topology window during rollout: legacy retries still broadcast to all groups.
• Redis Cluster key-slot errors if multi-stream reads cross slots.

Ramp-up

• Developers: low — the RabbitEvents listener API is unchanged; the work is idempotency review and removing reliance on --sleep.
• Ops/SRE: moderate — new key namespace, new monitoring, loss of broker UI, Streams debugging skills.
• Budget roughly one sprint for staging pilot, runbook rewrite, dashboard/alerting, and on-call training before production rollout; treat observability work as a prerequisite, not a follow-up.