Laravel Policy Soft Cache Laravel Package

Technical Evaluation

Architecture fit

• The package sits on top of Laravel's authorization layer (Gate/Policy dispatch) and memoizes policy verdicts — a decorator, not a new subsystem. No new infrastructure, no queue, no external cache dependency.
• The 1.6.0 change is a single compatibility PR (#21) adding Laravel 13 support. That tells us the package is actively tracking framework majors; it does not change the package's architecture or API surface.
• Highest value in request paths with repeated authorization checks: admin dashboards, list/index views full of @can, API resources serializing per-item permissions, and nested policy calls that re-dispatch the same ability.

Integration feasibility

• Standard Composer install with package auto-discovery; likely a publishable config and an opt-in mechanism (trait or gate wrapper). Integration effort is hours, not days.
• No data migration, no schema change, no runtime service to provision. Reversible by removing the dependency or disabling the flag.
• Because 1.6.0 is additive compatibility, adopting it for its own sake is not justified — its real value is unblocking or de-risking a Laravel 13 upgrade.

Technical risk

• Authorization caching is a security-sensitive boundary. Correctness depends entirely on cache-key derivation: user identity, ability name, model class and key, and any extra/contextual arguments. An incomplete key means a verdict computed for one subject is served for another.
• "Soft" caching implies short-lived/request-scoped retention, which bounds staleness but does not guarantee correctness within the request. Role, team, or tenant switches mid-request are the classic breakage scenario.
• Single-maintainer package sitting directly in the authz path is a concentration risk, though the code footprint appears small enough that forking or replacing is cheap.

Key questions

• Did 1.6.0 change the composer.json constraints — does it drop Laravel 10/11 or an older PHP minor, making this a disguised breaking change for our oldest service?
• Is the cache genuinely request-scoped and reset at request boundaries under Octane, Swoole, and queue workers, or is it a container singleton that can leak verdicts across requests?
• How are variadic arguments, closures, and Gate::any/Gate::none/before() hooks keyed and handled?
• Is there an invalidation path for mid-request permission changes (role grant, team switch, impersonation)?
• What is the CI matrix and test coverage for the L13 target, and is there a documented supported-versions policy?

Integration Approach

Stack fit

• Fits Laravel 11/12/13 applications on modern PHP. No conflict with Laravel's built-in Gate behavior expected, but any other package that also decorates the Gate (e.g. permission caching, Telescope, debug bars) should be checked for double-wrapping.
• Well suited to a service with heavy policy usage and a read-mostly authorization model; poor fit for a service where permissions mutate within a request.

Migration path

• composer require at ^1.6, publish config, enable per-policy via an explicit allowlist rather than globally. No application code change required.
• Rollback is a config toggle plus a dependency removal — treat it as low-commitment.

Compatibility

• Validate the composer constraint diff between 1.5.0 and 1.6.0 before bumping our lowest-common-denominator service; a compatibility PR can legitimately raise the floor.
• Confirm behavior against our authorization edge cases (super-admin before() bypasses, guest users, soft-deleted models, policy methods with extra arguments) with a small test suite in our repo, not just theirs.

Sequencing

1. Pin and evaluate in a non-critical service; read the diff of PR #21 and the composer.json change.
2. Write characterization tests for our own policies, including negative cases (assert a user cannot see another tenant's record) before enabling caching.
3. Instrument with Telescope/query log to confirm the expected query reduction — if the win is not measurable, stop.
4. Enable per-policy, starting with the highest-volume, lowest-blast-radius abilities (viewAny on index pages), leaving destructive abilities (update, delete, restore) on live evaluation.
5. Roll out to authz-critical paths last, behind a feature flag with instant disable.
6. Treat Laravel 13 support as the trigger to schedule the framework upgrade track, not as an isolated dependency bump.

Operational Impact

Maintenance

• Low ongoing cost: small surface, semver releases, and a maintainer who shipped L13 support in-cycle. Bus factor of one is real but mitigated by the small, forkable codebase.
• Assign a named owner in the platform team to track upstream releases and the supported-Laravel matrix.

Support

• Community OSS, no vendor SLA. Escalation path is upstream issues/PRs, with forking as the practical fallback. Acceptable for a non-critical optimization; questionable for anything in a regulated audit path without the characterization tests above.

Scaling

• Reduces database load in N+1 authorization patterns, which is exactly where large index views and API collections fall over. Being in-process memory, it scales horizontally with no shared cache to operate or invalidate across nodes.
• Benefits are per-request only; it will not reduce load across distinct requests, so it complements rather than replaces query tuning or response caching.

Failure modes

• Silent wrong verdict (most severe): an incomplete cache key or mid-request permission change serves a stale "allow." Mitigate with allowlisting, negative-case tests, and never enabling it on policies that consult mutable per-request state.
• Cross-request leakage: cache not reset under Octane/long-lived workers. Verify explicitly before enabling in any Octane deployment.
• Silent no-op: cache never hits due to key instability — a pure performance regression, benign but misleading in benchmarks; measure before claiming a win.
• Recursion/edge-case breakage: policies that themselves call Gate::check or rely on before() ordering. Cover with tests.
• Upstream abandonment: package drifts from future Laravel majors; detectable on the next framework upgrade, with a low-cost fork as the escape hatch.

Ramp-up

• Hours for a mid-level Laravel developer to integrate; the real ramp-up is judgment — teaching the team when not to enable it. One short internal write-up plus the characterization tests is sufficient onboarding.

Recommendation

• Adopt 1.6.0 as the version to standardize on, primarily because it keeps us on a supported path to Laravel 13. Treat actual caching enablement as a separate, gated decision driven by measured query reduction and a per-policy allowlist, with authz-critical abilities excluded from the first release.