Hybrid Cache Laravel Package

Technical Evaluation

hybrid-cache is a two-tier cache store for Laravel: an in-process (per-worker) layer fronting a shared backend, exposed through the standard Cache facade and contract. Release 0.2.0 makes two changes of consequence to a TPM's evaluation and nothing else:

1. Laravel 13 as the supported target. A version bump of this kind is a ceiling and a floor. It signals active maintenance against the newest framework major, but it also means the package now sits in a narrow compatibility band. Any service still on Laravel 11/12 either cannot use 0.2.0 or must pin 0.1.0 — which is now effectively unmaintained.
2. Cache touch support. TTL extension without rewriting the payload. Functionally small; architecturally useful, because it enables sliding-expiration and "refresh-on-read" patterns (sessions, rate-limit windows, feature-flag snapshots) without a read-modify-write on the backing store.

Architecture fit. The two-tier pattern is a legitimate fit for read-heavy, latency-sensitive paths — hot config, permission sets, tenant metadata — where the shared-store round trip dominates request time. It is a poor fit for anything with tight write-then-read consistency requirements, since the local layer is invalidated by TTL, not by write propagation.

Integration feasibility. Low effort to wire in: Composer install, package auto-discovery, a new entry under config/cache.php stores, and an env switch. Rollback is a config change, not a code change — provided the package is not used as a queue/session driver. The touch addition requires no consumer changes; it surfaces as existing Cache::touch() calls silently starting to work on this store instead of throwing.

Technical risk. Material, and concentrated in provenance rather than code quality. The package is at 0.2.0 with two merged changes, a single maintainer, and no stated support policy. The Laravel 13 jump is a strong compatibility statement but also evidence that the version surface is being narrowed aggressively rather than supported broadly. The core risk is coherency: writes to the shared store do not evict peers' in-process copies, so the effective staleness window is the local TTL, and that window is invisible to the application.

Key questions to put to the maintainer before adoption:

• What is the backing store, and is touch propagated to it or applied only to the local layer? Divergent TTLs between tiers is the most likely silent-corruption path.
• Is the in-process layer bounded (max entries / memory cap), and what is the eviction policy?
• Is there a documented invalidation/versioning mechanism (tags, key versioning, broadcast) to force a cross-node flush?
• What is the support commitment for Laravel 12, and is 0.1.0 receiving security fixes?
• Octane/FrankenPHP behaviour: does the local layer persist across requests in a worker, and how is that bounded?

Integration Approach

Stack fit. Only viable if the target application is on Laravel 13 (or the team is willing to pin 0.1.0 for an earlier major). Establish the framework version across all services first — this is now a hard gate, not a preference. Services on a mixed-version estate should be treated as separate adoption decisions.

Migration path. Do not replace an existing cache store wholesale. Introduce hybrid-cache as an additional named store and route specific, low-risk key families to it — those that are read-mostly, tolerant of seconds-level staleness, and not on a login/permission hot path. Keep the incumbent Redis/database store for everything else. The touch capability is the natural first workload: sliding-expiration keys currently paying a full read-modify-write can move over and be measured in isolation.

Compatibility. Verify against the actual cache usage inventory: tags (supported? if not, any Cache::tags() call site cannot move), atomic locks, increment/decrement, and Cache::remember under concurrency. Under Octane the in-process layer has a fundamentally different lifetime — a worker-lifetime cache rather than a request-lifetime one — so validate memory growth under sustained load before any production traffic.

Sequencing.

1. Confirm Laravel 13 across the estate; if not met, stop.
2. Add the store alongside the incumbent, disabled by default, in a non-production environment.
3. Move one read-heavy key family; instrument hit rate, p99 latency, and — critically — staleness incidents (reads older than the write that should have invalidated them).
4. Exercise touch paths explicitly, comparing TTL observed at each tier.
5. Canary one production service at low traffic share with a documented config-level rollback.
6. Only then evaluate broadening scope.

Operational Impact

Maintenance. Pin the exact version. Pre-1.0 with a single maintainer means minor bumps can carry breaking behaviour, and the 0.1.0 → 0.2.0 framework jump is the template: expect future releases to track the newest Laravel major rather than backport. Budget for an internal fork or a vendored patch if the maintainer goes quiet — assign explicit ownership of that contingency before adoption, not after.

Support. No commercial backing, no SLA, no published deprecation policy. Escalation path is a GitHub issue. That is acceptable for a peripheral latency optimisation and unacceptable for anything on a revenue path.

Scaling. The local tier scales with the fleet in the wrong direction: each additional worker or node carries its own copy, so aggregate memory grows linearly with instance count, and the staleness window becomes a function of per-node TTL configuration rather than a centralised setting. The shared tier absorbs the write load but sees reduced read load — measure the actual hit-rate shift, since a two-tier cache that mostly misses the local layer adds overhead rather than removing it.

Failure modes to plan for.

• Stale reads after write — the dominant risk; silent, and manifests as inconsistent UI or permission state rather than an error. Mitigate with short local TTLs and by excluding authorization data from the local layer.
• Two-tier TTL divergence — most plausible with the new touch support; a key can be live in one tier and expired in the other.
• Memory exhaustion under Octane if the local layer is unbounded.
• Cold-start amplification — after deploy or worker recycle, every node misses locally and hits the shared store simultaneously; the shared tier must be sized for that spike, not the steady state.
• Framework upgrade lock — a Laravel major lands and the package's next release drops the version you are on, forcing an unscheduled upgrade.

Ramp-up. Small surface area, but the failure modes are subtle and not self-announcing. Require the team to understand the two-tier invalidation model and to have a staleness diagnostic (key age at each tier) before moving any workload that touches user-visible state. Realistic estimate: half a day to integrate, two to three days to instrument and validate a single key family safely — the instrumentation, not the integration, is the cost.