Redis Laravel Package

Product Decisions This Supports

• Runtime standardization (build vs. buy): Decides whether we adopt a single Redis abstraction that behaves identically under PHP-FPM, CLI/queue workers, Swoole, and Workerman — or maintain divergent client code per runtime. This package's core value proposition is "one Redis client, every execution model."
• Go/no-go on an Octane/Swoole migration: Coroutine-safe connection pooling is a hard prerequisite for running Laravel under Swoole at scale. If a pooled client is viable, the latency/cost roadmap item is unblocked; if not, that roadmap item slips.
• Connection-pool architecture decision: Whether to solve Redis connection exhaustion (a classic failure mode in long-lived workers) at the client layer or via infrastructure (ProxySQL-style sidecars, PgBouncer equivalents like Twemproxy/pgpool-for-Redis). This package represents the "client-layer pooling" option.
• Dependency risk posture for the Redis layer: Redis sits under caching, sessions, rate limiting, queues, and locks — it is not a peripheral dependency. Evaluating a 5-star, 0-dependent library forces an explicit decision about vendoring, forking, or maintaining an internal fork.
• Feature/use-case fit: Best evaluated against concrete workloads — per-request caching, distributed rate limits, session storage, pub/sub fan-out, and queue backends in long-running workers — rather than as a general-purpose swap.
• Multi-runtime deployment strategy: If we serve the same codebase from both FPM (web) and Swoole (websockets, queues, high-concurrency endpoints), this package is directly on the critical path for that decision.

When to Consider This Package

Consider it when:

• You genuinely run mixed execution environments. The differentiator only pays off if the same code must run under FPM/CLI and Swoole or Workerman. A single-runtime stack gets no benefit and inherits all the risk.
• You need coroutine-safe pooling. If concurrent Swoole coroutines are sharing Redis connections today and you're hitting pool exhaustion or cross-coroutine state bugs, the optional connection pool is the specific feature worth a spike.
• You can absorb maintenance ownership. With 5 stars and 0 dependents, treat this as source code you are adopting, not a vendor you are relying on. Budget for reading the implementation, pinning a commit, and potentially forking.
• You're prototyping the Octane/Swoole path and need a credible reference implementation before committing to a commercial client or building one in-house.
• Your team is comfortable with the PHP extension boundary (phpredis vs. a pure-PHP protocol client) and can benchmark both under your actual concurrency profile.

Look elsewhere when:

• You are FPM-only. Use predis or the phpredis extension directly; the abstraction earns nothing.
• You want the Laravel-native path. illuminate/redis plus the phpredis extension is the supported, documented, battle-tested option, and integrates with Redis::connection(), Horizon, and the cache/queue drivers with zero glue.
• You need a maintenance and security-response guarantee. An unmaintained Redis client is a CVE and drift risk in a Tier-1 dependency. Prefer a project with active releases, an issue tracker with response times, and a real user base.
• You need clustering, Sentinel, or TLS out of the box — validate these exist and are exercised before assuming parity with phpredis.
• Your team cannot own a fork. If nobody can patch it, don't adopt it.

How to Pitch It (Stakeholders)

To executives: Redis underpins caching, sessions, rate limiting, and queues — it's infrastructure, not a feature. Today we run one Redis client for web traffic and a different approach for long-running workers, which means two code paths, two failure modes, and duplicated debugging. This package proposes a single client across all execution environments, plus connection pooling that directly reduces per-request latency and connection overhead if we move to Swoole/Octane. The catch is adoption risk: it has minimal community traction and no downstream dependents, so we would be adopting source code rather than buying a supported product. Recommendation: fund a two-week spike to benchmark it against phpredis and Laravel's native Redis layer under our real concurrency profile, and decide on measured results — not adopt it as a standard today.

To engineering: The appeal is narrow and real — one client, consistent semantics across FPM, CLI, Swoole, and Workerman, with optional coroutine pooling to stop connection exhaustion in long-lived workers. The cost is equally real: near-zero community, no dependents, no evident release cadence. Treat it as a reference implementation and a possible fork candidate. Evaluate on four axes: pool correctness under coroutine contention, behavior parity with phpredis on our existing command surface, cluster/Sentinel/TLS coverage, and reconnect/failure semantics when Redis blips. If it wins on the benchmark and we're willing to pin and own a fork, it unlocks the Octane migration; if it doesn't, we stay on the native path and revisit pooling at the infrastructure layer.