Cachelet Core Laravel Package

Technical Evaluation

Architecture fit. Cachelet Core is described only as a "core runtime," and v0.1.0 ships with no capability statement, API documentation, or usage example. On name and framing alone, the most plausible architecture is a cache abstraction layer — which is structurally favorable: caching sits at the perimeter of the domain, so a defect or a swap-out has a bounded blast radius compared with, say, an ORM or auth package. The material unknown is where it sits. If it registers as a Laravel cache store against Illuminate\Contracts\Cache\Store, integration is a config change. If it is a parallel abstraction, adoption means either a redundant second cache tier or a wrapper layer we own and maintain — a meaningfully worse outcome. The phrase "core runtime" also raises the possibility that v0.1.0 is a dependency of sibling Cachelet packages not yet released, in which case it delivers no end-user capability today and should be treated as a watch-list item rather than an adoption candidate.

Integration feasibility. Mechanically low: a Composer package in a monorepo split implies PSR-4 autoloading and standard version constraints. The real feasibility question is not install cost but verification cost — with no documented Laravel/PHP support matrix, no service provider reference, and no published config surface, we cannot estimate effort from the artifact. A read-only split additionally means any defect we hit cannot be patched at the package level without a fork; the contribution path runs exclusively through the upstream monorepo at github.com/oxhq/cachelet.

Technical risk.

• Pre-1.0 semver. At 0.1.0 the public API is explicitly unstable; breaking changes may land in any 0.x minor with no deprecation cycle.
• Split-repo divergence. The published package is a generated artifact. Release cadence depends on upstream CI; a silent failure in the split automation stalls releases with no signal in the consuming repository. Divergence between monorepo and split is a recurring failure mode for this pattern.
• Supply chain. New organisation (oxhq), first public release, no stated security policy, no signed releases or provenance attestation, no maintainer roster. Standard due diligence applies before this enters a production dependency graph.
• Scope opacity. "Core runtime" is unspecified; transitive dependency weight is unknown until a composer require in a scratch project.
• Namespace and key-space collisions with existing cache keys are unverifiable without source inspection.

Key questions.

1. What contract does it implement — Illuminate\Contracts\Cache\Store, PSR-16, PSR-6, or a bespoke interface?
2. Is v0.1.0 independently useful, or is it a dependency awaiting sibling packages?
3. Which PHP and Laravel versions are supported, and is that range enforced in composer.json?
4. Does it ship a service provider, publishable config, and deferred bindings, or is wiring manual?
5. What is the upstream release cadence and who is the accountable maintainer?
6. What is the documented behaviour on backend failure — fail-open to origin, or fail-closed?
7. Is the read-only split reproducible, and does Packagist resolve to the split or the monorepo?
8. Is there a SECURITY.md and a disclosure process?

Integration Approach

Stack fit. Unconfirmed pending a support-matrix read. The decisive test is whether Cachelet slots beneath the existing Cache facade without application-code changes. If it does, fit is high and the change is operationally reversible. If it requires call-site rewrites, fit is conditional and the change becomes a refactor with a caching motivation — a poor trade at v0.1.0 maturity.

Migration path. Treat this as additive and shadowable rather than a cutover. Sequence: install in a disposable branch, wire alongside the incumbent cache behind a feature flag, run dual-write with shadow reads against the existing store, and diff hit rate, latency, and value fidelity over a representative traffic window. Because the package is pre-1.0, favour an integration we can abandon by removing a flag over one that requires reverting application code.

Compatibility. Resolve constraints with composer why-not against our pinned illuminate/*, symfony/cache, and PHP versions before any code is written. Watch specifically for illuminate/support and psr/simple-cache version-range conflicts, and for a PHP floor above our oldest supported runtime. Verify the split repository's tags actually resolve — a split repo with no reachable tag is a dead dependency.

Sequencing.

1. Read the upstream monorepo README and any design notes; the split repo is a distribution artifact and will not carry the rationale.
2. Static review of the split source — size, dependencies, failure semantics — before any install.
3. Time-boxed spike (1–2 days) in a non-production service; produce a written support-matrix and failure-mode note.
4. Contract tests against our cache expectations, including backend-down behaviour.
5. Pilot behind a flag on one non-critical read path with a defined rollback.
6. Decision gate: promote, hold at watch-list, or reject. At 0.1.0 the default prior should be hold absent a compelling capability we cannot get from the existing Laravel cache stack.

Operational Impact

Maintenance. Read-only split is the dominant operational cost. Local patches are not viable as a steady state; any fix requires an upstream PR into the monorepo and a wait for the next split release. Budget for either a maintained fork (with its own rebase burden) or an accepted dependency on upstream responsiveness. Assign an owner to track upstream commits and split releases; without that, we discover divergence at the worst possible moment.

Support. No SLA, no LTS, no stated support window. v0.1.0 should be treated as vendor-supported on a best-effort basis only. Confirm who carries the pager if the cache layer misbehaves in production — if the answer is "the team that adopted it," that is a real and unbudgeted cost.

Scaling. Entirely a function of the backend it targets, which is currently unknown. Points to watch as load grows: per-request wrapper overhead, serialization cost on large values, key cardinality and eviction pressure, and memory ceiling on any in-process tier. Any per-request allocation added by a runtime layer is paid on every request, including cache hits.

Failure modes.

• Stampede / thundering herd on cold start or mass eviction, translating a cache problem into database load.
• Silent fail-open to origin, which masks the cache outage until the database saturates.
• Fail-closed, which is worse — a cache outage becomes a full application outage.
• Serialization drift across deploys or PHP upgrades, producing corrupt or unreadable entries.
• Version skew during rolling deploys if the entry format changes between releases.
• Unbounded key growth where TTLs are unset or namespacing is absent.
• Split-release staleness — a pinned version silently becoming the last one published.

Each of these needs an explicit documented answer before production, and the package currently documents none of them.

Ramp-up. Engineer ramp-up is modest in concept but front-loaded in investigation, because the documentation is a single paragraph. Assume the source is the specification. Realistic estimate: half a day to assess fit, one to two days to a defensible pilot, plus ongoing ownership of upstream tracking. The larger organisational cost is the precedent — adopting a 0.1.0 package with no support matrix, security policy, or maintainer accountability sets a bar that will be cited by the next proposal.

Recommendation. Baseline assessment, provisional. Place Cachelet Core v0.1.0 on a watch-list, not an adoption track. Commission the time-boxed spike only if a specific capability gap in our current cache stack is identified first; otherwise revisit at v0.3.0 or at first 1.0.0 release candidate, whichever comes first, and re-evaluate against documentation, a published support matrix, and a security policy.