go-cms-cache

Request a cache alias through the module-scoped manager with ctx.Caches().Store(alias), never resolving physical stores by technology name. Define deterministic keys, semantic dependency tags, and a TTL, then use a typed Remember helper for read-through loading.

A store is physical infrastructure like Redis or filesystem owned by the application layer. An alias is a module-local storage policy bound to a store, a key identifies the cached value, and a tag identifies dependencies that trigger invalidation.

A runtime-owned coherence mechanism tracks cache targets and fans dependency invalidation out to every participating alias and store. Modules must not iterate physical stores, hardcode other modules' aliases, or receive the global cache manager directly.

Use tags as the primary correctness mechanism for data with semantic dependencies and TTL as a safety bound. TTL alone is acceptable only for data whose staleness is inherently time-based and needs no mutation-triggered invalidation.

Cache failures follow a fail-open policy so domain operations continue from the authoritative source, since cache is an optimization rather than the source of truth. Hits, misses, read and write errors, and invalidation errors must still be logged and measured.

Required behavior-driven tests cover miss-then-load-then-hit, write followed by fresh read, TTL expiry, corrupt payload recovery, and backend failure handling. Cross-store changes need at least one test proving invalidation crosses the intended alias and store boundary.