Caching Laravel Package

Technical Evaluation

Architecture fit

• Overlapping capability, not a capability gap. Laravel already ships a mature cache subsystem (Illuminate\Cache) with stores, Cache::remember, tags, atomic locks, and events. nette/caching solves the same problem behind a different contract (Cache → Storage → Journal), so broad adoption means two cache abstractions in one codebase unless deliberately scoped to a bounded module.
• Where it is genuinely differentiated: dependency-based invalidation (Cache::load($key, $cb, $dependencies) with file/tag/callback/constant dependencies), capture() for atomic fragment caching, sliding expiration, namespaced keys, and bulk read/write. These are credible but narrow advantages over Laravel's tag + lock primitives.
• Where it fits: non-Laravel PHP services, shared libraries needing framework-agnostic caching, existing Nette/Latte footprints, and PSR-16 interop (adapter added in 3.3.1). It does not fit as the primary cache for a Laravel app, and it has no native Redis backend (File, Memory, Memcached, SQLite), which is the dominant Laravel production store — that is the single largest architectural gap to price in.
• Integration feasibility: installable via Composer, PHP 8.1+ (aligned with Laravel 10/11), but no service provider, facade, or auto-discovery. Integration is a build task: container bindings for Storage/Journal, config, key-prefix strategy, and either a PSR-16 seam or a custom Illuminate\Contracts\Cache\Repository adapter. T-shirt sizing: 2–4 day spike, 1–2 sprints for a thin bridge plus tests, days per bounded context to migrate.
• Technical risk: NOASSERTION license is a hard legal gate before any code lands; 435 stars / 0 listed dependents means thin ecosystem validation and due diligence shifting to us; the project has shipped BC breaks in minor releases (3.3.0 CacheExtension path change, SmartObject removal, Latte 2 dropped in 3.4.0); the internal FileStorage format and cross-method lock semantics are version-coupled (per docs/internals.md); there is a historical deadlock in fallback paths and an overloaded null trap that only surface under concurrency. Observability is a gap: no Laravel cache events, Telescope, or Horizon visibility without custom instrumentation.
• Key questions: What measured unmet need justifies this (miss cost, stampede, cross-framework sharing, legacy Nette)? Which bounded contexts, and who owns the bridge code? Does legal accept the license? How do we split invalidation ownership between the two stacks? Is Redis required, and if so do we fund a custom Storage implementation? Is it Octane-safe under long-lived workers? What is the rollback plan if the package stalls upstream?

Integration Approach

Stack fit

• Treat Laravel's cache as the default and nette/caching as an optional, isolated adapter — never a replacement. Bind Nette\Caching\Storage (File, Memcached, or custom) behind our own interface so application code depends on our abstraction, not the vendor.
• Use the PSR-16 adapter as the primary seam: it is the lowest-coupling path for shared libraries and permits incremental migration without rewriting call sites.
• Only build an Illuminate\Contracts\Cache\Repository adapter if a drop-in is mandatory, and accept that Laravel tags and nette dependencies are not semantically 1:1 — a leaked abstraction here is a maintenance tax.

Migration path

• Do not migrate existing caches. Introduce nette/caching for new, bounded read paths (expensive query fragments, computed payloads with file/constant dependencies) behind a feature flag, with distinct key prefixes to prevent collision.
• If a legacy Nette service exists, standardize semantics there first; reuse the same dependency model in Laravel only where behavior is provably equivalent.

Compatibility

• Pin PHP and Laravel matrix explicitly, plus ext-memcached and pdo_sqlite requirements; validate file permissions and absolute-path handling introduced in 3.3.0.
• Avoid caching Eloquent models or framework objects in nette storage — serialization expectations differ from Laravel's; cache scalars and plain arrays.
• Re-verify against each minor release; assume BC breaks are possible despite semver.

Sequencing

1. Legal/license review and a timeboxed spike with a written success metric.
2. Define the bounded use case, key namespace, and invalidation ownership doc.
3. Build the bridge + config + feature flag + tests (including concurrency/stampede cases).
4. Shadow or dual-read in staging to compare hit rates and staleness against Laravel's store.
5. Canary one low-risk path; expand only on measured latency/hit-rate win.
6. Formalize a deprecation path so the adapter can be removed cheaply.

Operational Impact

Maintenance

• Upstream is small and quality-focused (mandatory PHPStan, tightened PHPDoc, PHP 8.1–8.5 support), which is a positive signal, but we own the bridge, the config, and the version-compatibility testing forever. Budget a standing fraction of an engineer per quarter plus release-watch effort.
• Two dependency streams and two upgrade cadences; the NOASSERTION license means ongoing compliance ownership rather than vendor-backed assurance.

Support

• No commercial support, no Laravel-community familiarity, and a thin issue base. On-call runbooks must document new failure signatures; escalation is effectively "read the source and docs/internals.md."
• Team ramp-up is modest on the happy path (load/save/remove/capture) but the traps — dependency desugaring, overloaded null, cross-method locking — require deliberate study. Plan ~1–2 weeks for one engineer to reach proficiency and produce an internal note.

Scaling

• File storage is single-node; SQLiteJournal adds write contention and shared-filesystem risk. Memcached is viable but narrower than Redis for Laravel shops. Absent a custom Redis Storage, scaling story is weaker than the incumbent — that build cost belongs in the business case.
• Namespace clearing and journal GC have non-trivial cost at volume; validate under production-like key cardinality.

Failure modes

• Stale data from missed dependency invalidation — the highest-severity risk, since it is silent and hard to reproduce.
• Stampede/contention around atomic creation and the cross-method lock; test exception-in-fallback paths given the historical deadlock.
• Divergent TTLs and invalidation rules between the two stacks; a namespace/key-prefix mistake causes cross-contamination.
• Storage unavailability behaves differently from Laravel stores (no standard events/fallbacks), and long-lived Octane workers can retain stale in-process state.

Recommendation to stakeholders: fund legal review and a bounded spike only if a specific gap is measurable; otherwise invest in instrumenting and tuning Laravel's existing Redis/Memcached configuration. Keep nette/caching as a tactical interoperability option, not a platform standard.