x/data/cache Primer
x/data/cache Primer
Section titled “x/data/cache Primer”Experimental — API compatibility is not frozen. Evaluate before adopting in production. Check Release Posture for current maturity status.
Open this page after x/data Primer when the change is narrowly about distributed or Redis-backed cache topology: consistent-hashing rings, replication, failover, Redis client adapters, or leaderboard caching built on store/cache primitives.
x/data/cache is a subordinate package within the x/data family. Start distributed cache work in x/data before opening this package directly. For simple in-process caching, import github.com/spcent/plumego/store/cache and use cache.MemoryCache without opening x/data/cache at all.
Start here when
Section titled “Start here when”- you are implementing or modifying a consistent-hashing distributed cache (
distributed/) - you are adding Redis client adapter logic implementing the
store/cache.Cacheinterface (redis/) - you are building or tuning a leaderboard cache with ranking semantics (
leaderboard/) - you are adding replication or failover coordination to a distributed cache topology
Do not start here when
Section titled “Do not start here when”- simple in-process caching is sufficient — use
cache.MemoryCachefromstore/cachedirectly - the work is tenant-aware cache adapters that scope by tenant key — that belongs in
x/tenant/store/cache - the change is about stable
store/cacheinterface definitions — those are a kernel contract, not an adapter - the work is core bootstrap or application-level cache configuration
First files to read in the current repository
Section titled “First files to read in the current repository”x/data/cache/module.yamlx/data/cache/distributed/x/data/cache/redis/x/data/cache/leaderboard/
Concrete ownership examples
Section titled “Concrete ownership examples”Keep it in x/data/cache when the work is about | Move out when the work becomes |
|---|---|
distributed: consistent-hashing ring, node membership, replication factor, failover | tenant-aware cache scoping — use x/tenant/store/cache |
redis: Redis client implementing store/cache.Cache, pipeline helpers, TTL management | Redis cluster administration or connection pooling configuration |
leaderboard: ranked set semantics built on store/cache primitives | business-specific leaderboard rules or score computation domain logic |
| replication coordinator, hash ring membership updates | stable store/cache interface changes — those are kernel contracts |
Why this primer exists
Section titled “Why this primer exists”x/data/cache is often opened directly when the right starting point is cache.MemoryCache from store/cache for simple cases or x/data for topology placement. The subordinate relationship exists because distributed cache topology — sharding keys, ring membership, failover — is a topology concern that belongs in the x/data family rather than a separate top-level concern. Keeping them together preserves the invariant that topology decisions are explicit and reviewable.