salehhashemi/laravel-configurable-cache
A Laravel package for configurable caching that lets you define cache settings like TTL, keys, and stores per model or query instead of hardcoding them, keeping cache logic centralized and easy to adjust across your application.
Architecture fit. Laravel already ships a CacheManager with drivers, stores, tagged caches, and config/cache.php. A "configurable cache manager" therefore sits at the facade/config layer, not in the domain. The architectural question that decides value: does this package add a new capability (runtime store resolution per tenant/model/service, fallback chains, TTL policy centralization) or does it decorate behavior Laravel already provides? If it's the latter, adopting it trades a built-in framework contract for a third-party wrapper — net negative. Fit is strongest in multi-tenant or multi-store applications where cache backing varies by context and teams are currently scattering Cache::store(config(...)) calls across the codebase; centralizing that resolution is a real, if modest, win.
Integration feasibility. Likely composer require + package auto-discovery + a published config file. Low effort, low friction. The structural risk is that it wraps the Cache facade: any code path calling the facade directly bypasses it, producing inconsistent resolution. Feasibility is high; the value depends entirely on adoption discipline, not on installation.
Technical risk.
array/file when you expected Redis. That is a correctness defect disguised as a performance feature.Key questions. Does it replace or wrap CacheManager? Does it preserve tags, atomic locks, and increment semantics across every driver it abstracts? What is the Laravel/PHP support matrix and is there CI proving it? Is store resolution memoized per request, or recomputed on every call? What is the license intent, and can we get a canonical SPDX identifier or written clarification? Is there a stated support/versioning policy, or is this a personal project? What happens when a configured fallback store is absent in an environment — throw, or silently degrade?
Stack fit. Laravel-only, pure PHP. No infrastructure dependency beyond the cache backends already in use (Redis, Memcached, database, file). Critically, there is no data migration: cache is ephemeral by definition, so cutover and rollback are both cheap. That materially lowers the cost of trying it.
Migration path. (1) Inventory current cache usage — facade calls, Cache::store() sites, per-model caching, hardcoded TTLs. This inventory is the real deliverable; it tells you whether the package is worth it. (2) Pilot in one non-critical service behind a config toggle. (3) Wrap it in an internal interface so domain code never imports the package directly — this is the sequencing move that caps blast radius and makes the dependency reversible. (4) Expand service by service.
Compatibility. Verify against our exact Laravel major(s) and PHP version, testing at both the floor and ceiling of the supported range. Check specifically for conflicts with anything else that touches the cache manager binding. Pin the version; avoid caret ranges until cadence is established.
Sequencing. License and security review first — it's cheap and it can invalidate everything downstream. Then pilot, then interface, then rollout. Do not let the package become the de facto cache API before the wrapper exists, or removing it later becomes a refactor instead of a config change.
Fallback. Because this is a thin layer, a ~100-line in-house "resolve store from config" implementation is a credible substitute. Budget for it as the explicit Plan B if license or maintenance review fails; having that fallback is what makes piloting low-risk.
Maintenance. Small code footprint, so maintenance cost is concentrated in dependency risk rather than code volume. Single-maintainer, low-adoption project means we should assume eventual vendoring or forking. Track upstream releases; expect we own fixes.
Support. No vendor, no SLA, community-only issues. Any incident is ours. That is acceptable for a convenience layer and unacceptable for anything on the data path — so keep it out of serialization and key-strategy decisions we couldn't reproduce independently.
Scaling. This sits on the request path. Confirm resolution is memoized per request/worker and adds no extra connection or tag overhead. Require that behavior be identical under horizontal scaling: per-request config only, no process-local state that diverges across pods.
Failure modes. Wrong-but-silent store selection (writes landing in file/array instead of Redis) causing correctness bugs; stale reads after a config change; cache stampede if TTLs get centralized and uniformed across keys; partial failure when an environment lacks a configured fallback store. Mitigations: log the resolved store name in non-production, add a staging health check comparing configured vs. actual store, and keep TTL policy in application code rather than in this package's config.
Ramp-up. Low for any Laravel developer — a config file and a facade. The real ramp-up cost is organizational: getting teams to stop calling the facade directly, and documenting which context resolves to which store. Budget a short internal doc and a code-review checklist item.
Exit criteria. Define them up front: license resolved to a recognized SPDX identifier, adoption in N services, zero cache-attributable incidents for one quarter, or fork and own it.
How can I help you explore Laravel packages today?