Laravel Permanent Cache Laravel Package

Product Decisions This Supports

• Read-path latency and database load. The package caches Eloquent models with Cache::rememberForever() and invalidates them on create/update/delete. That directly attacks two PM-visible metrics: p95 request latency on read-heavy endpoints, and database CPU/connection pressure during traffic spikes. If your roadmap has a "reduce infra spend" or "improve perceived performance" line item, this is a credible lever.
• Build vs. buy for caching plumbing. The alternative is a hand-rolled model cache: a trait, a key scheme, event hooks, and a flush command. That's roughly a sprint of work plus permanent maintenance. This package collapses it to composer require plus one trait. Decision framing: buy the plumbing, own the risk.
• Roadmap sequencing — cache-heavy features. Catalog pages, CMS-driven content, pricing/tier tables, settings, category trees, public profile pages, and any "mostly read, occasionally written" entity. These are the natural candidates and they tend to cluster in the same quarter, so a single adoption unlocks several features at once.
• De-risking launches. For a launch expected to spike traffic (marketing push, partner integration, seasonal peak), permanent caching with event-driven invalidation is a cheap pre-launch insurance policy — it lets you size infrastructure for average load rather than peak.
• Scope boundary decision. What this package does not buy you: background/async recomputation. The tagline promises "update them in the background," but the described surface is rememberForever + model-event invalidation. That's invalidation-on-write, not stale-while-revalidate. If your product requirement is "users never wait on a cold cache," that requirement is still yours to build — likely a queue job plus a warm-up command. Confirm this before promising a latency SLO to stakeholders.
• Adoption as a signal, not a commitment. With 6 stars and zero dependents, you are an early adopter. That's acceptable for a peripheral, reversible concern (see next section) and unacceptable for anything on the revenue or auth path.

When to Consider This Package

Adopt when all of the following hold:

• The workload is read-heavy and write-light. Model caching pays off when reads outnumber writes by a wide margin. If writes are frequent, model-event invalidation thrashes the cache and you get the cost of caching with none of the benefit. Have engineering confirm the actual read/write ratio from metrics, not intuition.
• A short window of staleness is a product-acceptable outcome. Event-based invalidation fires on writes going through Eloquent. Writes via raw SQL, bulk insert(), queued jobs on other connections, or a second service hitting the same database will not invalidate. If the product cannot tolerate a stale price, balance, permission, or inventory count, this is the wrong tool.
• The blast radius is small and reversible. Wrap it behind a config flag, apply it to one or two models, and be able to turn it off in a deploy. If removal requires a data migration or touches many call sites, the reversibility argument collapses.
• Your stack is already on Laravel 12 (or the package demonstrably supports your version). The latest release is a Laravel 12 compatibility bump. If you're on 10 or 11, verify support explicitly — do not assume the constraint is tested.
• You have an owner. One named engineer accountable for dependency health reviews. Unowned pre-1.0 dependencies are the ones that break silently.

Look elsewhere — or wait — when:

• The data is correctness-critical. Payments, auth/permissions, entitlements, financial balances, inventory. The invalidation model is honest but incomplete; correctness here needs cache-through with authoritative reads, not permanence.
• You need background refresh, not just invalidation. The value proposition implies stale-while-revalidate. If that's the actual requirement, evaluate Laravel's own cache primitives, a queue-based warm-up you write yourself, or a mature cache library — and treat "background" as unproven in this package.
• You're pre-1.0-averse by policy. At v0.3.x there is no semver guarantee; a patch release can change defaults or config keys. If your org requires a support contract or a stability guarantee, this doesn't qualify. MIT, community-maintained, no SLA.
• You need to scale horizontally or run Octane. Cache driver behavior across multiple pods, Octane singleton/state safety, and stampede behavior under a cold cache are unverified. For a single-node app or a modest deployment this is fine; for high-concurrency architecture, require a spike first.
• The problem isn't actually caching. If read latency is the symptom of a missing index, an N+1 query, or an over-fetching endpoint, fix that first. Caching a slow query is how you get a fast bug. Measure before buying.
• Low adoption counts against you. 6 stars and 0 dependents means no community to catch regressions and no third-party writeups to learn from. That's priced in only if the use case is genuinely peripheral.

How to Pitch It (Stakeholders)

To executives (30 seconds). We're evaluating a small open-source add-on that caches frequently-read database records in memory and refreshes them automatically whenever the data changes. The upside is measurable: lower page latency and less database load, which lets us serve the same traffic on smaller infrastructure. The cost is a dependency — it's a young library with a single maintainer and no commercial support. Our recommendation is to pilot it on a non-critical, read-heavy area behind a feature flag, prove the latency and load numbers, and only then widen adoption. It is not appropriate for payments, authentication, or anything where a stale read would be a business problem.

To engineering (the honest version). MIT-licensed Laravel package, standard Composer install, one trait on a model, automatic invalidation via Eloquent events, configurable prefix and key generation, works with existing cache drivers. It's at v0.3.x — pin it exactly (0.3.17), don't use a caret range. Before we commit: confirm CI actually runs against our Laravel version, confirm it's safe under config caching and Octane, confirm behavior on a cold cache under concurrent load, and read the source — at 6 stars we may be fixing forward ourselves. One-day spike on a throwaway branch, run the full test suite with the package installed but unused to catch service-provider side effects.

To the team building on it. This removes the "we should cache this but nobody has time" backlog item. It does not remove your responsibility to know the read/write ratio, to keep writes going through Eloquent, and to define what staleness is acceptable for each model you apply it to. Budget roughly half a day per Laravel major to re-validate, and assign one owner.

What we're explicitly deciding against. We are not adopting this for revenue-path or correctness-critical data, and we are not adopting it bundled with a framework upgrade — those are separate decisions with separate rollback stories.