Hybrid Cache Laravel Package

Product Decisions This Supports

• Cache architecture / build-vs-buy: The package positions itself as a two-tier ("hybrid") cache layer, so the core decision it informs is whether to hand-roll L1/L2 orchestration (in-memory fast path in front of a persistent store) or adopt a small dependency that already does it. The touch addition is the concrete capability that makes this worth evaluating seriously.
• Feature enablement — touch support: touch extends a key's TTL without rewriting its value. That unlocks product-level patterns that are otherwise awkward or wasteful: sliding-expiration sessions, "keep warm while actively used" cached API payloads, rate-limit or lease-style windows, and long-lived reference data that should expire only after abandonment. Previously these required read-then-rewrite cycles, which cost serialization, network round-trips, and (on Redis) unnecessary write amplification.
• Roadmap / platform currency: The Laravel 13 upgrade is a signal about the project's maintenance posture and your own upgrade path. It directly affects whether this can be part of a Laravel 13 migration plan or is a blocker that must be resolved before upgrading.
• Latency and cost reduction use cases: Read-heavy endpoints, catalog/PDP-style pages, dashboard aggregates, and anything where the dominant cost is repeated deserialization or DB hits. touch improves hit ratios under sliding-expiration policies without additional write load.
• Diligence gating: This is a 0.x package with a single visible contributor and (per available data) no published documentation surfaced. That makes "do we want to own this code path" a decision in itself, not just a technical comparison.

When to Consider This Package

Consider it when:

• You genuinely need two cache tiers — typically a per-process/in-memory L1 for microsecond reads and a shared persistent L2 — and you don't want to maintain that orchestration yourself.
• You need sliding expiration semantics (touch) at scale, and rewriting values on every access is measurably expensive.
• You are on, or actively planning, Laravel 13 and want the dependency to be aligned rather than a migration blocker.
• The cached data is tolerant of L1/L2 divergence — e.g. read-through reference data, not authoritative state.

Look elsewhere when:

• A single tier is sufficient. Laravel's built-in cache drivers (Redis, Memcached, database, file) already cover this; adding a package here is net-negative complexity.
• Correctness tolerates no staleness. Multi-tier caches have inherent coherence problems — cross-node invalidation of L1 is the hard part of this problem space, and a 0.2.0 release note doesn't demonstrate it's solved.
• You run Octane, Swoole, or long-lived workers. Per-process in-memory caches behave differently when the process persists across requests; verify memory growth and invalidation before committing.
• Procurement/security review requires maturity signals. 0.x versioning, one maintainer, and a short changelog history are all real risk factors. If a cache regression takes down your read path, you need a maintenance story.
• Unclear Laravel 13 semantics. "Upgrade to Laravel 13" is ambiguous — it may mean added support or a hard requirement bump dropping Laravel 12 and below. Confirm before adopting; if it's a hard bump, teams not yet on L13 cannot use 0.2.0 and must pin 0.1.0.

Diligence items before adoption: confirm whether L13 is a floor or a ceiling; confirm whether touch is implemented for all supported drivers or only some (partial support is a common footgun and would make TTL behavior driver-dependent); check for a coherence/invalidation strategy; and get a read on the maintainer's release cadence.

How to Pitch It (Stakeholders)

For executives (one line): A small caching add-on that cuts database load and response times on read-heavy pages by keeping a fast in-memory copy in front of our persistent cache — and the new release lets us extend cache lifetimes cheaply instead of rewriting data on every hit. Low integration cost, but it's an early-stage community package, so we'd pilot it on one surface rather than standardize on it.

For engineering: Version 0.2.0 adds touch support — TTL extension without value rewrite — which removes the read-modify-write cost from sliding-expiration patterns, and brings the package onto Laravel 13. Worth a scoped spike: benchmark hit ratio and p99 latency on a read-heavy endpoint against our current single-tier setup, and explicitly test cross-node L1 staleness under invalidation. Treat the Laravel 13 change as a potential breaking constraint until confirmed, pin the version, and keep the existing cache abstraction in front of it so we can back out cleanly.