Lada Cache Laravel Package

Product Decisions This Supports

• Sequencing a performance initiative without buying infrastructure. Lada Cache is a "drop-in" lever: install via Composer, add a trait to a shared BaseModel, and every Eloquent and Query Builder read becomes cacheable. That makes it a candidate for a cheap-first roadmap item — ship caching before committing to read replicas, query rewrites, or a database tier upgrade.
• Build vs. buy for caching. The alternative is a bespoke layer of Cache::remember() calls plus hand-written invalidation. That work is invisible to users, easy to get wrong, and accumulates as a permanent maintenance tax on every feature team. Adopting an MIT-licensed package that derives cache keys from SQL and invalidates on writes replaces a recurring internal build with a one-time integration.
• Deferring database scaling spend. The vendor's own framing — 10–30% faster responses typical, up to 95% on pathological read patterns, "significant drop in DB load" — is exactly the input a PM needs to justify postponing a DB capacity purchase by a quarter or two. The strongest case is apps with redundant, complex, per-request Eloquent queries.
• Prioritizing which surfaces to optimize. Because caching is global by default but supports include/exclude tables and per-query withoutCache(), the PM can sequence rollout: enable broadly, then carve out freshness-critical paths rather than gate the whole program on a perfect policy.
• Making an argument about cache invalidation being a solved problem for this codebase. The pitch against manual caching has always been "invalidation is where it breaks." Row-level tagging with table-level fallback, plus invalidation on insert/update/delete/truncate, converts a research question into a configuration review.
• Operationalizing it. The console commands (lada-cache:flush, :enable, :disable), the LADA_CACHE_ACTIVE env flag, auto-flush after migrations, and Debugbar integration mean the PM can ask for a real rollout plan — shadow mode, per-environment flags, on-call runbook, hit-rate dashboards — rather than a binary flip.
• Explicitly not a lever for: write-path throughput, cold-start latency on unique queries, large-payload transfer costs (the README is honest that a ~500MB result won't get faster), or raw SQL (DB::select(), DB::statement()) which is uncached by design.

When to Consider This Package

Adopt when most of these hold:

• The stack is Laravel 12/13 on PHP 8.3+ (6.x). Older Laravel means pinning to 5.x — still supported back to Laravel 9, but you inherit a much older line.
• Redis is already provisioned, or is a cheap, uncontroversial addition. This package is Redis-only by design; there is no pluggable backend.
• The workload is read-heavy and Eloquent-centric, with repeated or redundant queries per request — dashboards, catalog/browse pages, reporting views, permission/tenant lookups.
• The schema uses standard single-column primary keys. Composite or unconventional PKs silently degrade to table-level invalidation — correct, but coarser and lossier.
• You have a plan for observability: Debugbar locally, plus a real Redis hit/miss metric in staging before production.
• A small amount of read-after-write staleness is tolerable, or you can route the few freshness-critical reads through withoutCache().

Look elsewhere — or scope down hard — when:

• Write-heavy workloads. Every insert/update/delete triggers invalidation; if writes dominate reads, you pay the tag bookkeeping for little benefit and risk churn-induced misses.
• Strict read-after-write consistency is a product requirement across most of the app. Per-query bypass exists, but auditing every call site is a real cost and a permanent one.
• Multi-connection or legacy database topology. Multiple connections are only supported through Lada's connection integration; models with $connection work, but hand-managed connections do not. Audit this before committing.
• Third-party packages define custom query builders. The README states these may bypass caching. That's a silent correctness-of-value problem, not a crash — you'll believe you're cached when you aren't.
• Raw SQL is a meaningful share of your query volume. Uncached by design; the ROI story weakens proportionally.
• You need pessimistic-lock semantics in hot paths — lockForUpdate/sharedLock bypass the cache in 6.x, which is correct but may undercut the expected win.
• You want an ecosystem-proven dependency. 592 stars, one visible maintainer, and 0 dependents is a thin adoption signal. For a revenue-critical system, treat this as a small, single-maintainer dependency with an implicit global effect on the data layer and price that risk honestly — fork-and-own, vendored patch capability, or a version pin plus a rollback plan.
• Your team cannot debug a transparent cache layer. Failures here manifest as stale data and confusing misses, not clean exceptions. Without Redis fluency on-call, this is a liability.

How to Pitch It (Stakeholders)

For executives: We can buy 10–30% faster response times and a meaningful reduction in database load for the cost of a Composer dependency and a small integration task — no rewrite, no new infrastructure beyond Redis we already run, no schema migration. It is MIT-licensed and actively maintained through Laravel 13. The trade-off is a new operational dependency and a small, single-maintainer risk that we mitigate with a version pin and a vendored-fork fallback. Recommendation: run it as a time-boxed, staged experiment on read-heavy surfaces with a measurable hit-rate target, and decide on broader rollout against that data rather than on the vendor's benchmarks.

For engineering: It intercepts the database layer by registering a Lada-aware connection that returns a custom query builder. Cache keys are derived from SQL + bindings + database; reads are served from Redis; writes invalidate by row-level tags with table-level fallback. Integration is a trait on a shared BaseModel plus a published config; per-query escape hatch is withoutCache(). Known edges we must design around and test for: non-standard or composite primary keys degrade to table-level invalidation; UNION/INTERSECT/advanced expressions fall back to table-level tagging; raw SQL isn't cached; third-party packages with custom query builders may silently bypass the cache; multiple connections require the integration path. We should ship behind LADA_CACHE_ACTIVE=false in production initially, wire a cache hit/miss metric into staging, and treat migrations plus the lada-cache:flush runbook as part of the change. Success criteria up front: measured p95 improvement and Redis hit rate on the target surfaces, plus zero stale-data incidents over a defined bake period.