Multi Level Cache Laravel Package

Product Decisions This Supports

• Build vs. buy for the caching layer. This package is a pre-built multi-level cache (fast local tier + shared tier) with an invalidation service, wired into Laravel's cache contracts. Choosing it over a bespoke caching layer is a "buy" decision that redirects engineering weeks from cache plumbing into product surface area.
• Performance/scale roadmap items. Read-heavy screens — dashboards, catalogs, pricing tables, feed pages — can be made "fast enough" without a database re-architecture or a dedicated caching sprint. That can defer or downsize an infrastructure investment on the roadmap.
• Invalidation correctness as a product requirement. The headline of v1.4.2 is an improved invalidator service. For products where stale data is a support ticket or a compliance issue (entitlements, inventory counts, permissions), the maturity of the invalidation path is the deciding factor — not raw hit rate. This release is a signal to re-check that path against your own staleness tolerance.
• Convention over configuration for feature teams. The generated cached-service pattern (services generated around cached reads) standardizes how every team touches the cache: one idiom, one review checklist, fewer bespoke Cache::remember calls scattered across controllers. That is a maintainability decision as much as a performance one.
• Onboarding and code-review cost. The new mixin on generated cached services improves IDE autocompletion, static analysis, and type inference on generated classes. Practical effect: generated code stops feeling like "magic" during code review and onboarding — a measurable drag on velocity in teams that lean on static analysis in CI.
• Use cases where it pays off fastest: multi-tenant apps with repeated hot reads, endpoints fronting rate-limited or paid third-party APIs, catalog/content pages with tolerance for seconds-to-minutes of staleness, and read amplification on a primary database during traffic spikes.
• Explicitly not a decision this supports: replacing a CDN/edge cache, cross-region data replication, or session/queue storage. Scope it as an application-tier cache only.

When to Consider This Package

Consider it when:

• You are on Laravel (or a PHP app comfortable with Laravel's cache contracts) and already run a shared cache backend — Redis/Memcached — alongside a per-request in-process tier.
• You have identifiable hot reads where a second tier measurably cuts database load or p95 latency.
• Your staleness budget is explicit and measured in seconds to minutes, not "must be exact."
• You want invalidation as a first-class, reusable service rather than ad-hoc Cache::forget calls spread across the codebase.
• Your team is small enough that a conventions-heavy package beats a hand-rolled abstraction, and you have one or two engineers who will read the source before trusting it.
• You are willing to wrap it behind your own thin interface so the dependency is swappable.

Look elsewhere when:

• Single-maintainer dependency risk is unacceptable for your tier. This is a community package with a narrow contributor base; there is no vendor SLA. If the cache is on a critical path with uptime commitments, budget for a fork-and-own plan or pick a vendor-backed alternative.
• The app is not Laravel-shaped, or you would fight the framework's cache contracts to adopt it.
• Your app is small enough that a single Redis tier plus Laravel's native cache tags covers you — the added tier and generated-service layer is complexity without payoff.
• You need strong consistency, transactional invalidation guarantees, or cross-region replication semantics. Multi-level caches trade consistency for latency by design; validate before committing either way.
• You cannot test invalidation behavior in CI. Adopting a caching layer you can't regression-test is how stale-data incidents happen.
• Your generated-code policy forbids committed or build-time generated classes, or your CI treats generated artifacts as a review burden.

Release-specific gate for v1.4.2: the invalidator service changed and generated cached services now emit a mixin. Both touch the invalidation and code-generation paths — the two areas most likely to break silently. Before upgrading, run your invalidation test suite against the new version and re-inspect generated output diffs; treat the mixin as low risk and the invalidator change as requiring verification.

How to Pitch It (Stakeholders)

For executives (one paragraph): We can take a meaningful load off the database and cut response times on our read-heavy screens without a re-architecture, by adopting an existing, actively maintained Laravel caching package instead of building our own. The trade-off is a dependency on a small open-source project with no commercial support, which we manage by wrapping it behind our own interface and keeping a fallback path. Cost is measured in days of integration and testing, not weeks of infrastructure work. The latest release improves cache invalidation — the part that determines whether users see stale data — and improves developer tooling around the generated cache classes, which lowers the ongoing cost of using it.

For engineering leads: The package gives us two-tier caching (in-process + shared) and an invalidation service behind Laravel's standard cache contracts, plus a generator for cached service classes. v1.4.2 is additive: it improves the invalidator service and adds a mixin to generated cached services, which means better IDE support and static analysis on generated code — a real DX win with no API break we've identified. Action items before adoption: (1) pin the version and review the invalidator diff, (2) add invalidation regression tests to CI, (3) wrap the package behind an internal cache interface so we can swap or fork, (4) confirm the generated-code step fits our build pipeline.

For the product/engineering decision meeting — the three questions to answer:

1. Which specific screens or endpoints are we caching, and what is the acceptable staleness window for each?
2. Who owns this dependency — who reviews upstream changes and holds the fork-and-own option if maintenance lapses?
3. What does "invalidation is working" look like as a test and as a production metric, and who watches it after launch?

If those three have named owners, the package is a low-cost, reversible bet. If they don't, the caching layer will still work — until the first stale-data incident, which is when the missing ownership becomes the expensive part.