Redis Laravel Package

Technical Evaluation

Architecture fit. fof/redis is not a framework-independent library but a Flarum extension, and Flarum sits on Laravel's Illuminate components (container, cache contracts, queue contracts). The extension's job is narrow: rebind Flarum's cache and queue resolvers to Redis-backed drivers using Illuminate\Redis rather than the default file cache and synchronous queue. That is the correct seam — it extends the container at boot rather than forking core, which means it should remain upgrade-tolerant as long as Flarum keeps honoring the cache/queue contracts. If your platform is a Laravel application proper, this package is not directly consumable; its value to you is either (a) you run Flarum, or (b) you are using it as a reference implementation for a ~200-line service-provider override in your own Laravel app.

Integration feasibility. High. Installation is a Composer require plus enabling the extension and pointing configuration at a Redis instance; the required PHP extension (ext-redis) or predis/predis is the only meaningful prerequisite. The code surface is small enough for a single engineer to read end to end in under an hour, which materially de-risks adoption. There is no schema change, no data migration, and no outward-facing API change.

Technical risk.

• Version coupling. The extension is bound to Flarum's internal cache/queue wiring. A Flarum minor that renames or relocates the queue factory breaks it silently or loudly depending on how the binding is written. Pin both.
• Bus factor. Three stars, zero dependents, single-maintainer community project. Treat this as code you are adopting, not a vendor you are buying from.
• Release provenance. The 2026-10-09 last-release date is inconsistent with the current date and should be treated as a metadata artifact until verified. Confirm the tag exists, is signed/tagged on the default branch, and CI passes against your target Flarum and PHP versions.
• Driver ambiguity. Confirm whether phpredis and prepredis are both supported and which is tested; the two have meaningfully different behavior under connection failure and clustering.

Key questions for the maintainer or your own spike.

1. Which Flarum core versions and PHP versions are in the support matrix, and is that matrix enforced in CI?
2. Does the extension configure cache and queue independently, or does it flip both at once? Can I take Redis cache without Redis queue?
3. What is the behavior when Redis is unreachable — hard failure, or graceful fallback to file cache?
4. How are cache key prefixes and queue connection names handled when Redis is shared with other applications or Flarum's own session store?
5. Is Redis Sentinel/Cluster supported, or single-instance only?

Integration Approach

Stack fit. Adopt this if you already operate Redis for sessions or jobs and your Flarum instance is beyond a single small node — specifically when you need multiple queue workers to drain email, notification, and search-index jobs, or when file-cache invalidation across nodes is causing stale reads. Do not adopt it for a single-node forum with low traffic; the default file cache and sync queue are strictly simpler with a smaller failure surface.

Migration path. Composer require → enable extension → switch cache store to Redis → verify hit rate and cold-start latency → switch queue to Redis → start workers. Keep sessions on their existing backend during the first cutover so a Redis outage does not log out every user. Rollback is the mirror image and should be rehearsed: disable the extension, revert config.php cache/queue settings, clear the file cache, restart workers. Because there is no persistent data owned by the extension beyond cache and in-flight jobs, rollback is cheap — provided jobs are drained before you flip the queue driver back.

Compatibility. Pin the extension version and the Flarum core version together in composer.json, and pin your Redis client choice. Validate on a staging clone that mirrors production PHP-FPM worker counts and Redis memory limits; most failures here are configuration-shaped, not code-shaped.

Sequencing.

1. Provision Redis with an explicit maxmemory-policy (noeviction or volatile-*; never allkeys-lru on a database holding queue data), a dedicated database index or key prefix, and persistence appropriate to your tolerance for losing queued jobs.
2. Stand up staging with the same worker topology.
3. Install and enable the extension in staging; exercise cache warm, cache invalidate, and a multi-job queue drain.
4. Load-test cache hit ratio and queue latency against the file/sync baseline.
5. Canary in production behind a maintenance window of minutes, with the rollback runbook open.
6. Only then increase queue worker concurrency — that is the actual payoff, and it should be a separate change from the driver swap.

Operational Impact

Maintenance. Low ongoing code maintenance, moderate ongoing ownership burden. The package is thin, so patching it yourself is realistic; budget for a fork or a local patch when Flarum core shifts. Re-validate on every Flarum upgrade, and treat "extension unmaintained" as a planned-for scenario rather than a surprise. Review the MIT license terms once — permissive, no obligations beyond attribution.

Support. Community Forum thread and GitHub issues; no SLA, no vendor. Your internal escalation path must terminate at "we fix it ourselves." For a package this small that is acceptable; it is not acceptable if the same team is also carrying three other unmaintained community extensions with no review capacity.

Scaling. This is the reason to adopt it. Redis-backed queues let you horizontally add workers, which is the bottleneck for notification and email fan-out on a busy forum; Redis cache removes filesystem cache contention and cross-node invalidation lag. Scaling Redis itself is straightforward until you need Cluster or Sentinel, at which point the extension's driver support becomes the constraint rather than Redis.

Failure modes.

• Redis unavailable → cache misses stampede the database and queued jobs stall or fail; without a circuit breaker or fallback this is a hard outage, not a degradation.
• Eviction policy misconfiguration → silent loss of queued jobs under memory pressure. This is the single most likely production incident.
• Key prefix collision with a co-tenant Redis or with the session store → subtle cross-environment cache poisoning.
• PHP-FPM worker count exceeding Redis maxclients → connection refused under peak concurrency.
• Worker processes silently dying after a deploy → queue depth grows without alerting.

Instrument all five: Redis availability, eviction count, queue depth and age, connection count, worker liveness.

Ramp-up. Roughly half a day for a PHP engineer already comfortable with Laravel's cache and queue contracts to read the source and validate in staging, plus a day of Redis operational setup and alerting. The engineering cost is not the package — it is provisioning Redis correctly and building the monitoring that turns "Redis died" from an outage into a page. The opportunity score on this package is high relative to its visibility because the integration is cheap and the scalability payoff is real; the score should be tempered by the maintenance exposure of a three-star, zero-dependent dependency, which argues for pinning, staging validation, and a rehearsed rollback rather than for skipping it.