Illuminate Adapter Laravel Package

Product Decisions This Supports

• Standardization of caching infrastructure: Enables adoption of PSR-6 across PHP services (Laravel + non-Laravel), reducing fragmentation and easing future migrations. Aligns with 12-factor app principles for stateless caching.
• Leverage existing Laravel investments: Reuses Laravel’s mature cache drivers (Redis, Memcached, database) while unlocking PSR-6 compatibility for tools like Doctrine, Symfony, or API Platform.
• Tag-based cache invalidation: Critical for scalable architectures (e.g., e-commerce, SaaS) where partial cache updates are frequent. Supports hierarchical tags (e.g., user:123:profile, product:category:electronics).
• Roadmap for modular caching: Future-proofs the stack for multi-vendor caching (e.g., mixing Redis and database caches) or serverless environments (e.g., AWS ElastiCache).
• Build vs. buy decision: Avoids reinventing PSR-6/Laravel integration; MIT-licensed, lightweight (~100 LOC), and maintained by the PHP-Cache org (trusted for PSR standards).
• Use cases:
  • Legacy Laravel monoliths: Gradually introduce PSR-6 without rewriting cache logic.
  • Microservices: Share cache pools between Laravel services and non-Laravel components (e.g., Symfony APIs, CLI tools).
  • Performance-critical paths: Benchmark against native Laravel cache to validate minimal PSR-6 overhead (typically <5%).
  • Testing/stubs: Use ArrayStore for unit tests with PSR-6 interfaces, reducing mocking complexity.

When to Consider This Package

• Adopt if:

  • Your stack already uses Laravel’s cache and needs PSR-6 interoperability (e.g., for Doctrine, Symfony, or other PSR-6 consumers).
  • You require tag-based invalidation for complex data relationships (e.g., user profiles, product catalogs).
  • You’re building a multi-framework PHP app and want to avoid cache duplication.
  • You prioritize long-term maintainability over short-term convenience (e.g., avoiding vendor lock-in to Laravel’s cache API).
  • Your team is familiar with PSR-6 or willing to adopt it for standardization.

• Avoid if:

  • You only use Laravel’s cache with no PSR-6 dependencies—native Laravel cache is sufficient.
  • You need advanced Laravel-specific features (e.g., cache()->rememberForever(), events) not exposed via PSR-6.
  • Your app is latency-sensitive (e.g., real-time systems) and cannot tolerate even minor PSR-6 abstraction overhead.
  • You’re using alternative PSR-6 adapters (e.g., predis/predis, symfony/cache) that already meet your needs.
  • Your team lacks PSR-6 experience, as adoption requires understanding interfaces like CacheItemPoolInterface.

• Look elsewhere if:

  • You need distributed cache coordination (e.g., Redis clusters, multi-DC setups) → Use predis/predis or php-redis directly.
  • You require advanced cache warming or priority-based eviction → Laravel’s cache:tag or custom solutions may suffice.
  • You’re on Laravel 10+ or PHP 8.2+ and risk compatibility issues (last release: 2022-01-17).
  • You need active maintenance—consider forking or evaluating alternatives like cache/array-adapter for simpler use cases.

How to Pitch It (Stakeholders)

For Executives: "This package lets us standardize caching across all PHP services using PSR-6, reducing technical debt and enabling easier adoption of new tools like Redis or Memcached. It’s a lightweight bridge to Laravel’s existing cache system—think of it as Lego blocks for caching that work anywhere. With zero lock-in and a MIT license, it’s a low-risk way to future-proof our stack for scalability and multi-cloud deployments. The overhead is negligible, and it pays dividends in maintainability."

For Engineering: *"By wrapping Laravel’s cache in a PSR-6 adapter, we gain:

• Portability: Swap cache backends (e.g., Redis → database) without changing app logic.
• Tags: Hierarchical cache invalidation (e.g., user:123 + user:123:orders) for complex data relationships.
• Future-proofing: Aligns with modern PHP standards, avoiding lock-in to Laravel’s cache API. Implementation: Replace Cache::store() with a 2-line adapter. Benchmarks show <5% overhead vs. native Laravel cache. Ideal for projects with >3 services or frequent cache updates."*

For Architects: *"This addresses two critical pain points:

1. Cache fragmentation: Unify caching across Laravel and non-Laravel services under PSR-6.
2. Invalidation complexity: Tags solve the ‘cache stampede’ problem for dynamic data (e.g., user profiles, product catalogs). Tradeoff: Minimal PSR-6 abstraction overhead for long-term flexibility. Recommended for scalable architectures where cache consistency is key. Caveat: Last release in 2022—validate compatibility with your Laravel/PHP versions before adoption."*

For Developers: *"Need to use Laravel’s cache in a Symfony service? Or want to test your PSR-6 cache logic with real Laravel drivers? This adapter lets you:

• Use RedisStore, DatabaseStore, or ArrayStore with PSR-6 interfaces.
• Leverage Laravel’s tagging system for easy cache invalidation.
• Zero refactoring: Just wrap your existing store in 2 lines of code. Example:

$pool = new IlluminateCachePool(Cache::store('redis'));
$item = $pool->getItem('key'); // PSR-6 compliant!

Pro tip: Start with ArrayStore for testing before moving to production drivers."*