Flarum Redis Laravel Package

Technical Evaluation

Scope correction that drives everything else. This is not a Laravel package. blomstra/flarum-redis is a Flarum extension (a Composer-installed plugin for the Flarum forum application). Flarum is built on a subset of Laravel's Illuminate components (cache, queue, database, events, validation), so the operational overlap with a Laravel stack is real, but there is no code-level reuse and no composer require into an existing Laravel app. Any evaluation premised on "we can leverage this in our Laravel services" is wrong. The correct framing is: "We run Flarum; do we adopt this extension to move cache and queue onto Redis?"

Architecture fit. The extension's job is narrow and well-bounded: it supplies/registers a Redis-backed cache store and queue driver for Flarum, plus the config plumbing to select them. That is a thin adapter over illuminate/cache and illuminate/queue semantics, which is the right place for this logic — it does not touch domain code, does not patch core, and is reversible via config. Low architectural blast radius, which is the main point in its favor.

Integration feasibility. Moderate — and the difficulty is not in the package. Two real prerequisites:

1. A Redis instance you own and operate, reachable from the Flarum web nodes and from queue workers. This is infrastructure work, not a plugin install.
2. A long-running queue worker process (queue:work / equivalent) under a supervisor. Flarum's async email/notification path silently degrades to synchronous or drops work if this isn't running. This is a new daemon in your topology.

There is also Flarum-specific friction: cache and queue drivers are typically set in config.php, not the admin UI, so changes are deploy-time configuration, not a toggle.

Technical risk.

Key questions.

• Does our Flarum version's core already support Redis cache and/or queue without this extension? If yes, this package is a convenience wrapper and we should not take the dependency.
• What flarum/core and PHP version ranges does the extension declare, and when was the last release?
• Are we already running Redis for anything else (sessions, app cache, rate limiting)? If not, is a forum of our size actually cache-bound, or is this premature optimization?
• What is the expected queue volume (emails, notifications, subscriptions)? If it's a few hundred/day, a synchronous path may be perfectly acceptable and the worker daemon is unjustified cost.
• Who owns Redis uptime, memory sizing, eviction policy, and persistence (AOF/RDB)? Cache and queue sharing one instance is the default failure and needs an explicit decision.

Integration Approach

Stack fit. Adopt only if Flarum is already a supported platform in the estate. The transferable asset is Redis operational competency (provisioning, eviction policy, persistence, monitoring, worker supervision), which the team likely already has from Laravel services — that makes this cheap to operate and makes the extension itself almost incidental. Treat it as a configuration and infrastructure change, not a software integration.

Migration path. Staged and reversible, which is the strongest argument for it:

1. Provision Redis (managed service preferred) with size headroom; decide cache/queue isolation up front.
2. Install phpredis in the Flarum image; build and smoke-test.
3. Add the extension via Composer; confirm Flarum's extension list registers it without conflict.
4. Move cache first, alone, with config.php pointing cache at Redis. Observe hit rate, memory, and DB QPS for a week. Rollback is a one-line config revert.
5. Then move queue, with separate DB/instance and noeviction. Stand up the worker under your existing process supervisor.
6. Only then tune (memory limits, maxmemory-policy, worker concurrency).

Splitting cache (step 4) from queue (step 5) is important: cache is a performance change with a clean rollback; queue is a reliability change with a new daemon and potential for silent job loss. Bundling them hides which one broke.

Compatibility. Confirm the extension's declared flarum/core range against the pinned version, and phpredis against the PHP runtime. If the Flarum instance is on an older minor, upgrading Flarum may be a prerequisite — which turns a small change into a platform upgrade and should be sequenced and staffed as such.

Sequencing relative to the roadmap. Low urgency. There is no user-visible feature here. It belongs in platform hygiene work, prioritized behind anything with a direct product outcome — consistent with the 0.38 opportunity score. Do it when Flarum is already being upgraded, or when there is an observed cache/queue bottleneck. Do not do it as a standalone initiative.

Operational Impact

Maintenance. Very low code-maintenance burden — the extension is a thin adapter and should need little attention. The real steady-state cost is infrastructure ownership: Redis capacity, eviction policy, persistence settings, upgrades, and monitoring. That cost exists whether or not you install this package, so it should be charged to the Redis platform, not to the extension.

Support. No commercial support contract; support is community- and sponsor-driven (Blomstra sells Flarum services, which gives a de facto escalation path if we become a customer). For a forum that is not business-critical, acceptable. For a customer-facing community with revenue attached, the lack of an SLA should be an explicit accepted risk, and the mitigation is "we can revert to file cache in minutes," which is credible here.

Scaling. Redis cache scales cleanly to the sizes any Flarum deployment will reach. Queue throughput scales with worker count and is bounded by the slowest job (typically SMTP delivery). The scaling ceiling for Flarum is almost always the database and PHP-FPM, not this layer — so this package does not meaningfully raise the ceiling; it removes a specific bottleneck. Do not oversell it.

Failure modes to design against.

• Redis unavailable → cache misses hammer MySQL; forum latency spikes or errors. Needs an alert and a documented revert to file cache.
• Worker not running → emails and notifications queue up and never send. This is the most dangerous failure because it is silent — no error surfacing to users, no obvious symptom until someone asks why they never got a password reset. Requires a worker liveness check and a queue-depth alarm, not just a process supervisor.
• Shared-instance eviction → queued jobs evicted under memory pressure. Mitigated by DB/instance separation and noeviction; this is the single highest-impact misconfiguration.
• Memory exhaustion → Redis restarts or refuses writes; both cache and queue fail simultaneously. Set maxmemory below instance size with alerting.
• Upgrade collision → a Flarum upgrade outpaces the extension's constraint, blocking the upgrade. Track the release feed.

Ramp-up. Small and mostly familiar. Any engineer who has run Laravel queues will recognize the worker model immediately. The genuinely new knowledge is Flarum-specific (config.php-driven driver selection, no admin toggle) and the failure-mode discipline above. Estimate: half a day for the install and config, one to two days to stand up Redis, worker supervision, dashboards, and the runbook. The runbook is the deliverable, not the Composer install.

Recommendation. Adopt opportunistically, not as an initiative. Trigger conditions: Flarum is already being upgraded, or there is measured cache/queue pain. First action is not an install — it is verifying whether Flarum core now covers this, and confirming we can isolate queue traffic from cache traffic. If either answer is bad, defer.