fido is a high-performance cache for Go, focusing on high hit-rates, high throughput, and low latency. Optimized using the best algorithms and lock-free data structures, nobody fetches better than Fido. Designed to thrive in unstable environments like Kubernetes, Cloud Run, or Borg.
It also features an optional multi-tier persistence architecture, so you can also think of it as an in-process redis/valkey replacement.
As of January 2026, nobody fetches better - and we have the benchmarks to prove it.
go get github.com/codeGROOVE-dev/fido
c := fido.New[string, int](fido.Size(10000))
c.Set("answer", 42)
val, ok := c.Get("answer")With persistence:
store, err := localfs.New[string, User]("myapp", "")
cache, err := fido.NewTiered(store)
err = cache.Set(ctx, "user:123", user) // sync write
err = cache.SetAsync(ctx, "user:456", user) // async writeFetch deduplicates concurrent loads to prevent thundering herd situations:
user, err := cache.Fetch("user:123", func() (User, error) {
return db.LoadUser("123")
})fido.Size(n) // max entries (default 16384)
fido.TTL(time.Hour) // default expirationMemory cache backed by durable storage. Reads check memory first; writes go to both.
| Backend | Import |
|---|---|
| Local filesystem | pkg/store/localfs |
| Valkey/Redis | pkg/store/valkey |
| Google Cloud Datastore | pkg/store/datastore |
| Auto-detect (Cloud Run) | pkg/store/cloudrun |
For maximum efficiency, all backends support S2 or Zstd compression via pkg/store/compress.
fido has been exhaustively tested for performance using gocachemark.
Where fido wins:
- Throughput: 727M int gets/sec avg (2.7X faster than otter). 70M string sets/sec avg (22X faster than otter).
- Hit rate: Wins 6 of 9 workloads. Highest average across all datasets (+2.8% vs otter, +0.9% vs sieve).
- Latency: 8ns int gets, 10ns string gets, zero allocations (4X lower latency than otter)
Where others win:
- Memory: freelru and otter use less memory per entry (49 bytes/item overhead vs 15 for otter)
- Specific workloads: sieve +0.5% on thesios-block, clock +0.1% on ibm-docker, theine +0.6% on zipf
Much of the credit for high throughput goes to puzpuzpuz/xsync and its lock-free data structures.
Run make benchmark for full results, or see benchmarks/gocachemark_results.md.
fido uses S3-FIFO, which features three queues: small (new entries), main (promoted entries), and ghost (recently evicted keys). New items enter small; items accessed twice move to main. The ghost queue tracks evicted keys in a bloom filter to fast-track their return.
fido has been hyper-tuned for high performance, and deviates from the original paper in a handful of ways:
- Size-adaptive small queue - 12-15% vs paper's 10%, interpolated per cache size via binary search tuning
- Full ghost frequency restoration - returning keys restore 100% of their previous access count
- Increased frequency cap - max freq=5 vs paper's 3, tuned via binary search for best average hit rate
- Death row - hot items (high peakFreq) get a second chance before eviction
- Size-adaptive ghost capacity - 0.9x to 2.2x cache size, larger caches need more ghost tracking
- Ghost frequency ring buffer - fixed-size 256-entry ring replaces map allocations
Apache 2.0
Cache.MemoryStats and TieredCache.MemoryStats sample the memory tier:
stats, ok := cache.MemoryStats(func(key string, value []byte) uint64 {
return uint64(len(key) + cap(value))
})
if ok {
log.Printf("entries=%d capacity=%d pending=%d estimated_bytes=%d",
stats.Entries, stats.Capacity, stats.PendingEntries, stats.Bytes())
}The callback estimates referenced storage beyond the inline key/value headers.
Use nil for structural accounting only. Sampling includes expired entries and
entries pending eviction because they still retain memory. It takes O(N) time;
run it periodically and retain the last sample when ok is false (writer busy).
The full scan and callback run without the FIFO writer lock. Counts and bytes
are approximate under concurrent changes, and shared backing storage may be
counted more than once. Estimates exclude allocator rounding, xsync map/lock
internals, in-flight loads and process overhead. Use Go heap profiles for an
independent measurement. This method never contacts a persistent Store.