Laravel Permanent Cache Laravel Package

Technical Evaluation

Problem fit. The package addresses a real, quantifiable problem: read-heavy Eloquent models whose data changes rarely but is queried on every request. Cache::rememberForever() plus event-driven invalidation is the canonical pattern for reference data — settings, categories, plans, taxonomies, CMS content, feature flags. The value is DB-load reduction and p95 latency improvement, not architectural change. It is an optimization layer bolted onto the model layer, not a platform.

Surface area. Deliberately small: one trait, model-event listeners, a config file for prefix and key generation, and flush helpers. Small surface means small blast radius and cheap removal. It also means the package does approximately what ~80 lines of Cache::rememberForever plus saved/deleted hooks would do. The TPM implication is that adoption cost and exit cost are both low — the decision should be made on convenience and ongoing maintenance, not strategic lock-in.

Where the value actually lands. Measure before adopting. If a model's read path is a small fraction of request time, or the query is already index-covered and sub-millisecond, permanent caching buys complexity for nothing. Target models with expensive queries (joins, aggregations, JSON columns) or extreme read frequency, and only those.

Technical risk.

• Invalidation coverage. Eloquent events fire on model save/update/delete. They do not fire on Model::query()->update(), raw SQL, seeders, or writes from another service sharing the database. With rememberForever, any such gap produces indefinite staleness — a silent, unbounded failure rather than a TTL-bounded glitch. This is the dominant risk and must be audited per model.
• Cache driver semantics. "Works with existing drivers" is true but misleading in production. Array and file drivers are per-process/per-node; on multi-node or Octane deployments only Redis or Memcached are correct. Misconfiguration surfaces as intermittent wrong data that looks like random bugs.
• Serialized model drift. Cached values are whole Eloquent models. A migration that renames or drops a column, or a deploy that changes casts/accessors, leaves stale payloads hydrating into the new class. Cache outliving a deploy is a real outage vector and needs a mandatory flush step.
• Pre-1.0 status. v0.3.x carries no semver breakage guarantee; ^0.3 admits breaking patch releases. With 6 stars and 0 dependents there is effectively no ecosystem validation — we would be among the first production users and would absorb bug discovery.
• Bus factor. Single-maintainer 0.x package. Assume we own the code the moment we adopt it.
• Unboundedness. No TTL, no size cap. Models with large row counts or blob columns can silently consume Redis memory and evict unrelated keys (sessions, queues).

Key questions.

1. Which models and endpoints are targeted, and what share of p95 latency and DB CPU do they represent?
2. Does anything write to those tables outside Eloquent — mass ->update() calls, imports, admin SQL, another service?
3. What cache driver runs per environment, and do app, queue, and worker nodes all point at the same instance?
4. How large is the cached dataset per model, and is there a Redis memory budget and eviction policy that tolerates it?
5. Does key generation support multi-tenancy, and does the config prefix isolate us from other apps on shared Redis?
6. What is the flush story on deploy — pipeline hook, artisan command, or manual step?
7. Are soft deletes and restore covered by the invalidation listeners?
8. Is Laravel 12 a tested CI target or only a widened illuminate/* constraint?
9. What is rollback — remove trait plus flush — and how fast can it ship if needed?

Integration Approach

Stack fit. Standard Composer package on Laravel's service-provider and config-publish model; Laravel 12 supported as of v0.3.17. No schema changes, no migrations, no queue requirement. Invalidation is synchronous in the writing process, which keeps the mental model simple but means write latency now includes a cache delete. A shared cache backend (Redis/Memcached) is a hard prerequisite in any multi-node environment.

Compatibility. Pin exactly ("vormkracht10/laravel-permanent-cache": "0.3.17"), not a caret range. Review composer.lock diffs in PRs. Confirm Laravel 12 is a tested target rather than a constraint bump by checking the package's CI matrix or running its suite on our PHP/Laravel combination before committing.

Migration path. There is no incumbent, so this is additive rather than a migration.

1. Baseline instrumentation: query counts, DB CPU, and p95 latency on candidate models and endpoints.
2. Spike in a branch with one low-risk model (settings or categories). Verify hit behaviour, invalidation on save/update/delete, and key isolation.
3. Audit every write path to that table for non-Eloquent updates; add explicit flush calls where found.
4. Run the full app test suite with the package installed but only one model opted in — catches service-provider side effects and config-cache interactions.
5. Staging soak with realistic traffic and a Redis memory check.
6. Production one model at a time, behind a config flag that can disable behaviour without a deploy.

Sequencing. Keep this off the critical path of any framework upgrade — framework first, confirm stability, then package. Within the package, sequence models by risk: reference data first, user-visible content second, anything transactional or financial last, if ever. Each model is an independent invalidation contract and deserves its own release.

Alternative to price in. The same behaviour is a trait plus saved/deleted listeners plus rememberForever — roughly one day of in-house work. Compare that against the ongoing cost of reviewing a 0.x dependency every Laravel release. If the package saves a day but adds recurring dependency-review overhead, building in-house can win on total cost of ownership despite losing on initial effort.

Operational Impact

Maintenance. Small but non-zero. Review on each Laravel major and each 0.x bump; verify key format and config defaults haven't shifted; re-validate invalidation coverage whenever a new write path touches a cached table. Assign an explicit owner — unowned 0.x dependencies are the ones that break silently. Roughly 2–4 hours per Laravel major plus ad-hoc patch review.

Support. Community-only via GitHub issues. No SLA, single maintainer, minimal adoption. Assume we fix forward ourselves: read the source before adopting, not after, and keep a fork or patch path. The small surface area is what makes this tolerable — the whole package is absorbable in-house if the maintainer goes dark.

Scaling. Reads become single cache round-trips and invalidations are O(1) deletes, so hot-path scaling is generally favourable versus Postgres. Three things to watch: (a) cold-start stampede after a deploy or flush — warm serially or accept one slow window; (b) Redis memory — set per-model key budgets and an eviction policy that cannot take out sessions or queue keys; (c) cache-hit ratio as a first-class per-model metric, alerted on, since a sudden drop usually signals a prefix or connection misconfiguration rather than a code change.

Failure modes.

• Silent indefinite staleness from writes outside Eloquent — most likely and most damaging; mitigate with a write-path audit plus a periodic reconcile-and-rewarm job.
• Cross-node inconsistency from file/array drivers or split Redis instances — presents as "wrong data on some requests".
• Deploy-time deserialization errors when cached models outlive a schema change — mitigate with a mandatory flush in the deploy pipeline.
• Memory pressure and eviction of unrelated keys from unbounded caching — mitigate with dataset sizing and per-model budgets.
• Dependency drift under a 0.x pin — mitigate with scheduled composer outdated --direct review and an owned dependency-health check.
• Missed invalidation on soft delete, restore, or bulk restore — verify event coverage per model during the spike.

Ramp-up. Low for a mid-level Laravel developer: one trait, one config file, one concept. Budget one to two days end-to-end for the first model including the write-path audit and tests; subsequent models are a few hours each. The real organizational cost is the runbook — flush-on-deploy, cache-health monitoring, and a maintained list of tables with non-Eloquent writers that must call flush explicitly. If that scaffolding isn't funded, the recommendation is not to adopt: permanent caching without invalidation discipline converts a performance win into a data-integrity incident.