Namespaced Cache Laravel Package

Product Decisions This Supports

• Cache-key isolation strategy (the real decision). The package forces a decision on how cache keys are scoped: ad-hoc string concatenation ("user:{$id}:profile") versus a consistent, enforced namespace convention (tenant:{id}:module:{name}). Even if you don't adopt the library, this is the decision to make — cache-key collisions and cross-tenant leakage are product-risk issues (data exposure, incorrect feature flags, stale pricing), not just engineering hygiene.
• Build vs. buy — and here the answer leans "build" or "already have." The package is a thin decorator around Psr\Cache\CacheItemPoolInterface (~one class, prefixing keys). The honest comparison is: one Composer dependency with 14 stars, 0 dependents, and a read-only split repo vs. ~30 lines of in-house decorator you fully control. Take the dependency only if you're already standardized on the php-cache PSR-6 stack.
• Multi-tenant / multi-brand scoping. The clearest product use case: isolating cached data per tenant or brand, and making "clear this tenant's cache" a supported operation instead of a Redis SCAN-and-pray script. Verify namespace-scoped flush behavior in a spike before you promise it to stakeholders.
• Retrofit without a rewrite. As a decorator, it lets you layer scoping onto existing cache call sites rather than touching every get/put. That's a genuine roadmap lever if you have a large legacy cache surface and no appetite for a cache refactor this quarter.
• Explicit non-decision: this is not a Laravel feature. Laravel's cache layer is CacheStore/CacheManager and PSR-16 (Psr\SimpleCache), not PSR-6. There is no service provider, no config/cache.php driver, no Cache::namespace() method, and no facade integration in this package. Do not let a roadmap item ("adopt namespaced cache in Laravel") assume drop-in behavior — it would require a bridge (Laravel store → PSR-6 pool → NamespacedCachePool → PSR-16 adapter → back into Laravel), which is more machinery than the problem warrants.

When to Consider This Package

Adopt if:

• You are already running the php-cache family (cache/redis-adapter, cache/adapter-common, etc.) and want namespace scoping with a one-line decorator instead of touching every call site.
• You have a hard requirement for per-tenant cache isolation and want the prefixing logic to live in one auditable place rather than scattered across the codebase.
• You are willing to pin the version and accept that a bug fix means either a monorepo PR or a local fork.
• You want a reference implementation to crib from for your own decorator.

Look elsewhere (or build the 30-line version) if:

• You are Laravel-first. Use what's already in the box: the prefix option on cache stores, separate stores per tenant in config/cache.php, and Cache::tags() on Redis/Memcached/DynamoDB/array for grouped invalidation. A small custom CacheStore decorator gives you the same ergonomics without the PSR-6 bridge.
• You need tag-based or grouped invalidation. Namespacing is prefixing, not tagging. This package does not give you "flush everything tagged products" semantics.
• You need maintenance guarantees. Read-only split repo (issues/PRs route to the monorepo), 14 stars, 0 dependents, no evidence of production adoption, and release notes that just say "see changelog." No Laravel or PHP version compatibility statement is published.
• You need PSR-16. Wrong abstraction level entirely.
• Your keys are already consistently prefixed and enforced in code review — the decorator is pure indirection at that point.

Minimum bar before adoption: a one-day spike proving (a) the bridge into your actual runtime works, (b) namespace-scoped flush behaves as expected, (c) measured overhead on your hot paths, and (d) a documented fallback if the package goes quiet.

How to Pitch It (Stakeholders)

For executives — one paragraph, framed as risk, not technology: "We need a consistent way to keep one tenant's cached data from colliding with another's. This library solves that pattern, but it's a small utility with essentially no industry adoption (14 stars, zero dependent projects), so I don't recommend betting the platform on it. The recommended path is to adopt the pattern — a namespaced key convention enforced in one place — and implement it with either Laravel's built-in store prefixes and tags or a small internal decorator. Cost is roughly a day of engineering; the benefit is preventing cross-tenant data exposure and making per-tenant cache clearing a supported operation. If engineering already uses the php-cache PSR-6 stack, we can take the package as-is for near-zero effort; otherwise the internal version is the lower-risk call."

For engineering — direct and specific:

• What it actually is: new NamespacedCachePool($hierarchyPool, 'acme') — a PSR-6 CacheItemPoolInterface decorator that prefixes keys with a namespace. That's it. The README is the entire documentation; there is no Laravel service provider, facade, config driver, or Cache::namespace() API.
• Where it fits: only if we're on the php-cache PSR-6 adapters. In Laravel, the equivalent is the store prefix, per-tenant stores, Cache::tags(), or a custom CacheStore decorator (~30 LOC).
• Risk: read-only repo, monorepo-routed PRs, 0 dependents, no published version-compatibility matrix. Pin the version and vendor the class if we proceed.
• Ask: one spike. Prove the bridge (if Laravel) or the direct integration (if PSR-6), benchmark the prefix overhead on our hottest cache path, and confirm namespace-scoped flush semantics. If the spike exceeds a day, we build the decorator ourselves — the API surface is one constructor and prefixing.