Product Decisions This Supports
- Framework-level architecture bets.
marko/cache is the abstraction layer, not a cache backend — it defines the interfaces and infrastructure that every cache adapter (file, Redis, Memcached, array, database) must satisfy. Adopting it is a decision about contracts, not about a specific vendor, which means the team can swap backends later without touching application code. That is a strategic decision worth making explicitly and early.
- Build vs. buy vs. use-the-framework. The realistic alternative to this package is not a competing library — it is either (a) a hand-rolled cache wrapper, or (b) adopting a full framework (Laravel, Symfony) that ships its own cache contracts. Choosing Marko means choosing this contract by default. A PM should decide whether the team is willing to own a bespoke abstraction or wants an ecosystem with a larger hiring pool and more third-party adapters.
- Performance and cost roadmap inputs. Cache TTL policy, cache-tag invalidation, stampede/thundering-herd protection, and per-environment backend selection are all product-visible levers: they determine page latency, infrastructure spend, and how quickly content changes propagate to users. This package is where those levers get standardized, so roadmap items like "reduce p95 latency" or "cut Redis spend 30%" route through it.
- Multi-tenant and multi-environment requirements. Because the contract is backend-agnostic, it supports shipping a single codebase where dev uses an in-memory/file backend and production uses a distributed one. That affects deployment strategy and environment parity decisions.
- Use cases it enables: read-through caching for expensive queries and API responses, fragment/partial caching for rendered views, rate-limit and session-adjacent state storage, and feature-flag or config caching. Each is a feature decision that becomes cheap once the abstraction exists and expensive if it does not.
When to Consider This Package
Consider it when:
- You are already building on the Marko framework. This is a read-only split of a monorepo component; its value is inseparable from the framework. Outside Marko, there is essentially no reason to adopt it.
- You need a stable cache contract with pluggable backends and want the framework to own that surface rather than your application team.
- You are standardizing caching across multiple services or teams and want one interface, one set of semantics, and one place to audit invalidation behavior.
- You are small enough that a lightweight, MIT-licensed, dependency-free contract is preferable to pulling in a heavier ecosystem component.
Look elsewhere when:
- Ecosystem maturity is a hard requirement. With zero stars and zero dependents, there is no evidence of production usage, no community of adapter authors, and no third-party tutorials. Hiring, onboarding, and debugging all rely on a single upstream maintainer. Laravel's cache component or Symfony's Cache contracts have vastly more battle-testing.
- You need out-of-the-box adapters. Interfaces alone do not cache anything; confirm that concrete drivers exist and are maintained before committing. If you would have to write the Redis adapter yourself, you are not really buying a cache layer.
- You need advanced semantics — cache tags, atomic locks, stampede protection, TTL jitter, or observability hooks. Verify these are in the contract rather than assuming they can be bolted on.
- The framework itself is not yet a committed decision. Do not let a transitive dependency make a platform choice for you.
How to Pitch It (Stakeholders)
For executives: This is a small, MIT-licensed infrastructure component inside the Marko framework that standardizes how our applications cache data. It does not add a vendor relationship or a licensing cost, and it lets us change caching backends — or drop caching entirely in a given environment — without rewriting application code. The trade-off is ecosystem maturity: this component has no independent adoption, so our leverage comes from the framework's health, not from the package's. Recommend it only as part of a Marko adoption decision, not as a standalone bet.
For engineering: The package is a contract layer — interfaces plus the plumbing to register and resolve cache stores. Treat it as the boundary we program against: application code depends on the interface, adapters are configuration. Before committing, we should (1) inventory which concrete adapters already exist and who maintains them, (2) confirm support for the semantics we actually need — TTLs, tag-based invalidation, atomic locks, and stampede protection, (3) verify multi-store and per-environment configuration, and (4) check whether the abstraction leaks, e.g. whether TTL units, serialization behavior, and key namespacing are specified or left to each driver. If we need to write adapters ourselves, the real cost is adapter ownership plus the maintenance risk of a single-maintainer dependency — budget for that explicitly, and plan an exit path in case we need to swap the contract out.