Laravel Policy Soft Cache Laravel Package

Product Decisions This Supports

• Performance/roadmap: authorization as a latency lever. Policy soft-caching targets a recurring hot path — repeated Gate::allows / @can checks in list views, dashboards, and API index endpoints that re-resolve roles, teams, or tenant scopes per row. Adopting it converts "rewrite the permission model" into a small, reversible optimization.
• Build vs buy: don't hand-roll memoization. The alternative is scattering ad-hoc per-request caches inside individual policies, which drifts across teams and is invisible in review. A dedicated package centralizes the behavior with one config surface.
• Framework upgrade planning (this release). 1.6.0 adds Laravel 13 support. That is a compatibility-only change — no new API, no migration work — but it removes this package as a blocker in the Laravel 13 upgrade plan and is a positive maintenance signal. Treat it as "cleared for the upgrade train," not as a feature to schedule.
• Feature use cases that justify evaluation: admin/back-office panels with dense permission-aware UI, multi-tenant apps where permission resolution is a multi-query join, and read-heavy endpoints where the same subject/ability pair is checked many times per request.

When to Consider This Package

Consider it when:

• You have measured evidence (query counts, p95 latency) that authorization checks are a real cost, not a suspected one.
• Policy outcomes are deterministic within a request — the same user/ability/object yields the same answer.
• The team wants a small, single-purpose dependency over a bespoke caching trait, and accepts a low-ceremony integration (composer require + config, no schema changes).
• You want the option to remove it cheaply if results disappoint.

Look elsewhere or skip when:

• Permission state can change mid-request and must be immediately visible (grant/revoke flows, impersonation switching, approval workflows) — any caching layer risks stale grants.
• You already run a cached authorization layer (e.g. permission-package caching or a Gate-level cache store); stacking caches makes invalidation reasoning much harder.
• You need a per-evaluation audit trail of authorization decisions — caching collapses repeat evaluations and weakens that record.
• The authorization path is security-critical and you require a vendor with active, broad maintainership; this is a small, single-organization package, so plan for version pinning and an exit path.

How to Pitch It (Stakeholders)

For executives: A low-cost, low-risk performance improvement for permission-heavy screens, adopted via a single dependency rather than internal engineering work. The 1.6.0 release confirms it tracks current Laravel versions, so it won't hold up our framework upgrade. Exposure is contained: it is removable without data migration.

For engineering: Add the package, enable caching for policy checks, and prove the win with before/after query counts and p95 latency on one representative endpoint. Requirements before rollout: pin the version, add tests covering cache invalidation and mid-request permission changes, and document which policies are safe to cache (deterministic, non-audited). 1.6.0 requires no code changes — it is purely Laravel 13 compatibility, so slot the upgrade independently of feature work.