Flarum Redis Laravel Package

Product Decisions This Supports

• Scaling posture for a Flarum-based community product. This package is the decision-enabler for "can we serve forum traffic from more than one app server?" — it wires Redis in as the shared cache and queue backend, which is the prerequisite for horizontal scaling, sticky-session-free deploys, and cache consistency across nodes.
• Build vs. buy (build vs. adopt). The alternative is writing and maintaining your own cache/queue driver against Flarum's internals. With 14 stars, this is not a "buy" in the commercial sense — it's an adopt-and-own decision: take an MIT-licensed, small-surface integration instead of spending engineering weeks on plumbing that provides no product differentiation.
• Infrastructure spend vs. application optimization. Offloading cache and async work to Redis is typically cheaper and faster than vertically scaling the database. This package is the lever that makes that trade available without a fork of the forum core.
• Feature roadmap gated on async processing. Anything that shouldn't block a page render — notification fan-out, digest emails, webhook delivery, search indexing, badge/reputation recalculation, media post-processing — depends on a real queue. Adopting this package unblocks those roadmap items rather than each one being individually justified.
• Hosting/multi-tenancy strategy. If the product direction is managed or multi-tenant forum hosting, a shared Redis layer per tenant (or namespaced keyspace) is a standard pattern; this is a small but real input to that architecture decision.
• Risk acceptance on dependency footprint. Low stars (14) and a modest opportunity score mean the PM decision is explicitly "we accept maintenance risk in exchange for speed of adoption," with a named owner and a version-pinning policy.

When to Consider This Package

Consider it when:

• The forum is past single-server comfort — multiple app nodes, or a load balancer in front, and file/database cache is producing stale or inconsistent reads.
• Redis already exists in your stack or is trivially available as managed service (ElastiCache, Azure Cache, Upstash, Redis Cloud). If you'd be standing up Redis solely for this, the calculus changes.
• You have queued work — email, webhooks, indexing — currently running synchronously and hurting p95 latency.
• Your team is comfortable with Flarum's extension model and Composer-based deployment, and can read the source (it's small) rather than relying on vendor support.
• You need an MIT-licensed, low-legal-friction path — no procurement, no license review beyond a glance.

Look elsewhere or defer when:

• Traffic is modest and single-node; Flarum's default file/database cache is adequate, and adding Redis adds an operational dependency with no user-visible benefit.
• You need Redis Cluster/Sentinel topologies, TLS specifics, or failover semantics guaranteed by a support contract — this package's bus factor is small; you'd be your own support.
• Version drift risk is unacceptable. A 14-star extension tracks Flarum core loosely; if you upgrade Flarum aggressively, budget for occasional patching or a fork.
• Your organization requires first-party or vendor-backed dependencies for anything in the request path.
• You're not actually on Flarum — this is Flarum-specific, not a general Laravel cache/queue package; standard Laravel predis/phpredis configuration already covers non-Flarum services.

How to Pitch It (Stakeholders)

To executives: This is a small, free (MIT), low-risk infrastructure connector that lets our forum run across more than one server and stops slow background work from delaying page loads. It's the difference between "scale up the database" and "scale out the app," and it usually reduces hosting cost per visitor. It is not a product feature — it's plumbing — so the upside is latency, headroom, and unblocked roadmap items, not new capabilities. The main risk is maintenance: it's a niche open-source component with a small maintainer base, so we should pin the version, keep it out of any critical-only path, and assign an owner.

To engineering: Drop-in Redis cache and queue for Flarum, configured rather than coded. Removes the shared-cache inconsistency we get from per-node file caching, and gives us a real queue for notifications, webhooks, and indexing. Small code surface, easy to audit, easy to fork if upstream stalls. Ask: verify against our Flarum version, confirm key prefixing/isolation if we share a Redis instance, and document the fallback path if Redis is unavailable.

To the product team: Adopting this is what makes several "nice to have" async features cheap to build later, and it's reversible — a config change, not a migration. Treat it as an enabling decision, not a bet.