z-go-caching
Installation
SKILL.md
Go caching
Cache is an optimization on top of a source of truth, never a second source of truth. Every pattern below exists to protect that invariant under real failure: Redis down, two thousand goroutines missing the same key at once, a write racing an invalidation.
Client choice
go-redis v9 (redis/go-redis) |
rueidis (redis/rueidis) |
|
|---|---|---|
| API shape | idiomatic per-command methods — rdb.Get(ctx, key) |
fluent command builder — client.B().Get().Key(k).Build() |
| Pipelining | opt-in, explicit Pipeline() / TxPipeline() |
automatic for concurrent calls, no code change |
| Client-side caching | not built in | opt-in server-assisted caching via DoCache(ctx, cmd, ttl) |
| Ecosystem | largest — most examples, redisotel OTel bridge, every tutorial assumes it |
newer, both maintained under the redis GitHub org, growing fast |
| Default | reach for this first | reach for this once auto-pipelining or client-side caching removes a measured bottleneck a profiler pointed at |
Both are maintained by the Redis org now — this isn't a "official vs community" choice, it's ubiquity vs throughput headroom. Don't switch clients speculatively; go-redis's synchronous per-command API is easier to read in a code review and matches what the rest of the team already knows.
Cache-aside is the default pattern
Read-through on miss, delete on write. No write-through, no cache warm-up job, no separate write path into the cache — one shape to reason about.