Cache Bundle Laravel Package

Product Decisions This Supports

• Feature-level: declarative caching on read-heavy endpoints. The package's core value proposition (annotation-driven cache control around methods) maps directly to "make this slow page/endpoint fast without hand-writing cache boilerplate in every controller." If a feature's success metric is p95 latency or database load, this is a candidate enabler.
• Roadmap: standardizing a cache-aside convention. Adopting (or copying) an annotation-based contract is a roadmap decision about how the team expresses caching in code — a convention question, not just a library question. This package is a reference point for that debate.
• Build vs buy: leans "build" or "borrow," not "buy." With ~36 stars and 0 dependents, this is not a de-risked dependency; it is a small, single-maintainer utility. The realistic decision is adopt-and-vendor, fork, or reimplement the ~annotation-listener pattern in-house (likely a few days of engineering), not "commit to this vendor."
• Framework fit is itself a decision. This is a Symfony bundle, not a Laravel package. For a Laravel codebase there is no adoption path short of porting the idea — so the decision becomes "do we want annotation/attribute-style cache declarations in Laravel, and what's the idiomatic equivalent?" (middleware, response cache packages, or explicit Cache::remember at the repository layer).
• Use cases where it earns its keep: internal tools, admin panels, legacy Symfony apps already annotation-driven, prototypes where speed-to-demo matters more than library provenance.
• Decisions it explicitly does not settle (must be decided separately): invalidation strategy (TTL vs event-driven), cache stampede/thundering-herd protection, tag-based purging, multi-tier (in-process vs Redis) topology, and tenant/user-scoped key design. A PM who adopts this expecting it to answer those will be disappointed.

When to Consider This Package

Consider it when:

• The codebase is Symfony 3.x/4.x-era and already uses annotations on controllers/services — this bundle's model fits that world with near-zero conceptual friction.
• You need per-method caching quickly for a bounded scope (one or two hot endpoints), and the team is comfortable vendoring or forking a small MIT-licensed component.
• You want a reference implementation to study before writing your own thin cache-decorator — the annotation-to-cache-key mapping is a cheap pattern to copy.
• Your team accepts maintenance ownership: pinning a fork, auditing it, and being the de facto maintainer.

Look elsewhere when:

• The app is Laravel. Wrong framework entirely; use the framework cache, a response-cache middleware package, or explicit Cache::remember in a repository/service layer. Do not port a Symfony bundle to satisfy a Laravel mandate.
• The app is Symfony 6/7. Doctrine annotations are deprecated/removed in favor of PHP attributes; a bundle built around annotation reading is a migration liability, not an accelerator. Prefer Symfony's native cache contracts plus attributes, or a maintained HTTP-cache bundle.
• You need production-grade guarantees: tagging, stampede locks, async invalidation, observability hooks, multi-region. This is not that.
• Supply-chain risk is unacceptable: 36 stars, 0 dependents, no visible downstream usage means no community safety net, no CVE-watch crowd, and no "someone else will notice first." For payments, auth, or anything on a compliance path, disqualify on provenance alone.
• You'd spend more time evaluating it than reproducing it. At this size, the honest comparison is "this package vs. ~2–4 engineer-days of our own code," and the in-house version wins on fit and ownership.

How to Pitch It (Stakeholders)

For executives (30 seconds): "A small open-source utility that lets developers declare caching with a one-line annotation instead of hand-writing cache logic. It's cheap to try and MIT-licensed, so there's no procurement cost — but it's effectively a personal project: modest traction, no downstream users, and it targets an older Symfony version than ours. Recommendation: use it as a reference for a one-week spike, not as a platform dependency. If the spike shows wins, we implement the same pattern in-house behind our own interface — roughly a few engineer-days — and keep full control. Risk of adoption as-is: low dollars, moderate technical debt, no external support."

For engineering (the real conversation):

• What it is: a bundle that reads method-level cache annotations and wraps invocation with cache get/set; the "abstraction" is thin — a key resolver plus an interceptor.
• Framework caveat: it's Symfony, not Laravel. If the target product is Laravel, we're evaluating the pattern, not the dependency.
• Effort: treat as a spike — 2–3 days to wire against a real Redis backend, 1–2 days to measure. In-house equivalent, scoped to our needs, is ~2–4 days and removes the fork burden.
• What we'd own if we adopted: patch cadence, annotation-reader compatibility with our Symfony version, key-generation correctness (user/tenant scoping), and the test matrix across cache backends.
• Exit path (mandatory): hide it behind an internal CachePolicy/decorator interface so the underlying mechanism is swappable within one PR. Never let annotations be the only place caching semantics live.
• Success metrics for the spike: cache hit ratio on targeted endpoints, p95 latency delta, backend QPS reduction, and — critically — zero correctness regressions from stale reads. If invalidation can't be made trustworthy in the spike, kill it regardless of latency wins.

Decision-log line to record: "TbbcCacheBundle evaluated as a pattern reference only; rejected as a production dependency due to framework mismatch, annotation deprecation risk, and zero downstream adoption. In-house thin cache decorator approved pending spike results."