Laravel Permanent Cache Laravel Package

Product Decisions This Supports

• Build vs. buy on perceived performance. This package implements a stale-while-revalidate pattern for Laravel's cache: values are served permanently from cache while a queued job refreshes them in the background. That lets you ship a latency improvement without re-architecting the underlying query or API integration — a cheap way to buy a release cycle.
• Feature go/no-go for "expensive but tolerant" surfaces. Dashboards, analytics rollups, catalog/listing pages, pricing tables, third-party API proxies, and public marketing endpoints are all candidates. The deciding question is whether a few seconds to a few minutes of staleness is acceptable to the business — if yes, this unlocks features that would otherwise be blocked on query optimization or vendor rate limits.
• Roadmap sequencing. If p95 latency on expensive reads is a recurring complaint, this is a "stop the bleeding" item you can slot before the deeper work (indexing, denormalization, read replicas, CDN strategy). It also reduces pressure on third-party rate limits and DB capacity, which can defer infrastructure spend.
• SLO and UX commitments. Because users never hit a cold cache after warm-up, you can promise flatter tail latency rather than average latency. That is a materially different (and easier to defend) reliability target than a standard TTL cache.
• Risk posture on dependencies. MIT license, single-purpose, small surface area — the lock-in cost is low and the code is replaceable. The decision is less "can we adopt this" and more "do we accept the maintenance risk of a small, low-adoption package." v0.3.17 shipped Laravel 12 support, which is a positive maintenance signal and keeps the package viable through your next framework upgrade — but it remains a pre-1.0, low-adoption dependency, so the "we may own this code" assumption still stands.

When to Consider This Package

Adopt when most of these are true:

• You have read-heavy, compute-heavy operations (complex Eloquent aggregates, multi-table joins, external API calls) where the first computation is slow but the result changes slowly.
• Staleness is tolerable and definable. You can write down an acceptable freshness window (e.g., "leaderboards may lag 60s") and defend it to stakeholders.
• You already run queue workers reliably. This package's promise depends entirely on queue health; if your queue is best-effort, the "permanent" cache never refreshes and users see stale data indefinitely.
• You need a low-effort win and can absorb the cost of forking if needed — with minimal stars and dependents, you are effectively an early adopter and should assume you may own the code. The Laravel 12 support in v0.3.17 reduces near-term upgrade risk, but it does not change the ownership assumption.
• You are on a supported Laravel version — current releases target modern Laravel (12 supported as of v0.3.17). Confirm your version against the package's compatibility matrix before committing; pre-1.0 packages can drop or add support between minors.
• Your cache backend is shared/centralized (Redis, Memcached, database) so multiple app servers see consistent values.

Look elsewhere when:

• You need strong consistency or read-your-writes — permanent caching is the wrong primitive; use explicit invalidation or short TTLs.
• The problem is write-heavy or per-user data — hit rates will be poor and refresh jobs will thrash.
• You need fine-grained invalidation (tag-based, per-entity busting) as a first-class feature; verify support before committing, and budget for building it on top if not.
• Traffic is low. If cache misses are rare, the added complexity and queue load buy you nothing; measure first.
• You have compliance or data-residency constraints on cached third-party data, or a platform team standardizing on a first-party caching layer — don't fragment the caching story.
• The real fix is cheap — if a missing index or a single eager-load solves it, do that instead.

Regardless of choice, instrument before and after: cache hit ratio, refresh job duration and failure rate, queue backlog, and p95/p99 endpoint latency. Track the age of served values so you can prove the freshness SLA holds.

How to Pitch It (Stakeholders)

To executives: This is a small, free, MIT-licensed Laravel add-on that makes slow pages feel instant. It caches the expensive work and refreshes it in the background, so customers stop waiting on spinners and we stop hammering the database and third-party APIs. It's a low-cost way to improve perceived speed on our heaviest screens this quarter, and it defers infrastructure spend. It also just picked up Laravel 12 support, so it won't force a rewrite at our next framework upgrade — and the code is small and replaceable, so we can walk away easily.

To engineering: It gives us stale-while-revalidate semantics without hand-rolling a refresh scheduler in every service. It is current with the framework (v0.3.17 adds Laravel 12 support), which removes the upgrade-blocker objection. Costs: we must guarantee queue reliability (this is the real dependency), define a freshness window per cached surface, and add observability for refresh lag and job failures. Risks: the package is still 0.x with minimal adoption, so plan for a thin internal wrapper — isolate it behind our own interface, pin the exact minor version, and be ready to fork. It is not a substitute for fixing bad queries; treat it as a latency buffer that buys us time to do the real optimization work.