Cache Bundle Laravel Package

Product Decisions This Supports

• Build vs. buy vs. borrow for caching. The package is best used as a decision input, not a dependency. Its design — declarative method-level caching, pluggable adapters, configurable keys and TTLs, explicit invalidation — gives product and engineering a concrete vocabulary for scoping a caching initiative without committing to the codebase.
• Prioritizing performance work. Read-heavy endpoints, expensive domain computations, and repeated third-party calls are the surfaces this pattern targets. Its annotation/decorator ergonomics show how little call-site churn a caching layer can require — useful when estimating time-to-market for a p95 improvement.
• Forcing the staleness conversation. The bundle's key-generation and eviction model makes "how stale can this surface be?" an explicit product decision (pricing, inventory, profile, feed each deserve their own answer). Use its concepts to structure that discussion even if you never install it.
• Dependency-risk register. Development has explicitly moved to TheBigBrainsCompany/TbbcCacheBundle; 14 stars and 0 dependents is near-zero ecosystem signal. That belongs in the risk view whenever a platform or PHP-version upgrade is scoped.
• Framework-fit reality check. Despite being catalogued here as a Laravel/PHP package, it is a Symfony bundle with kernel wiring, a DI extension, and Doctrine annotation-reader coupling. That mismatch is itself a product finding: it argues for adopting a framework-native cache contract rather than a portable-looking bundle.

When to Consider This Package

Consider it (narrowly) when:

• You maintain a legacy Symfony 2.x/3.x application that already annotates services for caching, and a rewrite is off the table.
• You are prepared to vendor or fork the code — named owner, pinned version, and acceptance that upstream fixes will not arrive.
• You want it as a design reference for key generation and eviction semantics you intend to reimplement on modern primitives (PSR-6/PSR-16, Symfony Cache, or Laravel's Cache facade with tagged Redis stores).
• Your cache scope is single-node or shared Redis/Memcached with simple TTL plus explicit evict, and no tag, stampede, or multi-region requirements.

Look elsewhere when:

• You are starting a new project, or targeting PHP 8.x / current Symfony or Laravel. Laravel 10+ requires PHP 8.1+, which this package's era does not cleanly support.
• You need HTTP/shared caching, stampede protection, cache tagging, or multi-tier (edge + app) caching — out of scope for a method-level bundle.
• You need invalidation events across services, multi-region consistency, or cache observability (hit ratio, key cardinality, invalidation lag). None of that instrumentation exists here.
• Your org requires maintained dependencies with a security response process — a redirected README with zero dependents fails that bar.
• You are evaluating the successor (TbbcCacheBundle): assess it separately on the same criteria; do not inherit this score.

How to Pitch It (Stakeholders)

To executives (one paragraph): We evaluated kitano/cache-bundle as a fast route to caching expensive Symfony service calls. It solves a real problem and its invalidation model is a useful template, but the project is explicitly superseded (development moved to TbbcCacheBundle), has 14 stars and no known dependents, and carries no maintenance or security commitment. Recommendation: do not adopt it as a dependency. Use its concepts to define our caching and staleness policies, then implement on the framework's maintained cache component — or evaluate the successor fork only if we specifically need annotation-driven caching with minimal code change.

To engineering (summary): Treat this as a pattern, not a package — and note it is Symfony-shaped, not Laravel-shaped. Extract two things: (1) the annotation/decorator approach for opt-in method caching, and (2) the key-generation plus explicit-eviction contract. Reimplement on PSR-6/PSR-16 via Symfony Cache, or on Laravel's Cache facade with tagged Redis stores plus a thin Cacheable trait or repository decorator. If a legacy app already depends on it, fork into the monorepo, pin it, and budget migration as tech debt — and do not let it spread to new services.

Framing for the build-vs-buy conversation: the marginal cost of adopting this bundle is low today and high in 12–18 months (unsupported PHP/framework upgrades, self-owned forks, no upstream fixes). That asymmetry — cheap now, expensive later — is the whole argument, and it is the one to make to whoever owns the roadmap.