Caching Laravel Package

Product Decisions This Supports

• Build vs. buy (scoped): nette/caching is a credible, actively maintained commodity caching library, but it is not a replacement for Laravel's cache layer. The PM decision it informs is narrow: keep Illuminate\Cache as the platform default and evaluate this package only where it closes a specific, measured gap. This is a "buy optionally, not a build" signal—not a platform standardization mandate.
• Performance and scale roadmap: If we can evidence that cache miss cost, stampedes, or repeated expensive queries drive latency, the package offers relevant primitives—pluggable backends (file, memory, Memcached, SQLite), time and sliding expiration, bulk read/write, dependency-based invalidation, and atomic cache capture. That gives us a concrete option to cost against "tune Laravel's existing drivers."
• Ecosystem and legacy consolidation: Where we own Nette/Latte or other non-Laravel PHP services, adopting this library can unify cache semantics and de-risk migration. Its value is highest as an interoperability layer across heterogeneous PHP services—not as a new internal standard inside a Laravel-only codebase.
• PSR-16 interoperability: The PSR-16 adapter (added v3.3.1) enables incremental migration and shared libraries that expect a framework-agnostic contract. This is a tactical adoption lever, not a strategic reason to swap Laravel's stack.
• Maintenance and risk posture: Recent releases (v3.3.x–v3.4.2) are quality-focused—stricter PHPDoc and type hints, mandatory PHPStan in CI with official Nette rules, support for PHP 8.1–8.5, no API churn. That supports "safe to depend on for a bounded use case," not "safe to make a platform bet." Counterweights: NOASSERTION license, zero listed dependents, 435 stars—so due diligence lands on us.
• Feature prioritization: Absent a concrete unmet need (file-based dependency invalidation, cross-framework cache sharing, legacy Nette compatibility), roadmap effort is better spent instrumenting and tuning Laravel's cache drivers, key design, tags, and locks rather than adding a second abstraction.

When to Consider This Package

Consider adoption when:

• We maintain a non-Laravel PHP service or shared library needing framework-agnostic caching with selectable backends.
• We have an existing Nette/Latte footprint and want consistent cache behavior and migration continuity.
• We need PSR-16 interoperability and can accept an adapter layer.
• There is a bounded use case where dependency/tag invalidation, atomic capture(), or bulk operations materially outperform our current driver configuration—demonstrated by measurement, not intuition.
• We are prepared to own a thin Laravel bridge, dual observability, and explicit invalidation semantics between the two cache systems.

Look elsewhere when:

• This is the primary cache for a Laravel application—use the Cache facade and supported drivers (native tags, events, atomic locks, Octane/Horizon alignment, team familiarity).
• We require native service provider/facade integration without custom glue.
• We need enterprise support, procurement approval, or clear licensing—NOASSERTION must be legally reviewed; do not assume MIT.
• We rely on ecosystem validation; thin adoption signals shift all due diligence onto our team.
• The underlying goal is simply "make Laravel faster"—first measure and tune Redis/Memcached/file cache, query patterns, and cache key design.

How to Pitch It (Stakeholders)

• Executives: "Caching is a real performance lever, and Laravel already gives us a supported, well-understood cache system. nette/caching is a lightweight, actively maintained library with multiple backends, dependency-based invalidation, atomic fragment caching, and PSR-16 interoperability—but it is not a drop-in Laravel replacement. Adopting it broadly would mean a second cache abstraction, adapter work, and legal review, since the license is marked NOASSERTION. Recommendation: do not make it a platform standard. Fund a time-boxed evaluation only if we can show a measured gap in Laravel's cache, or if we need cache sharing with non-Laravel Nette/PHP services."
• Engineering: "nette/caching is worth a spike only against a concrete unmet need—file-based dependency invalidation, shared caching with non-Laravel PHP services, or PSR-16 interoperability. The API is clean, recent releases enforce PHPStan and support PHP 8.1–8.5, and bulk operations are useful. It does not implement Laravel's cache contracts, so we'd own a bridge, two invalidation models, and split observability. Default stays Laravel cache on Redis/Memcached; treat this as an optional adapter, scoped to a service boundary, with a documented invalidation contract and rollback path."