The right choice depends less on "which cache is fastest" and more on what problem you're trying to solve. These libraries solve different problems, and many production systems use more than one.
Here's how I'd think about them.
| Library | Best for | Avoid if | Notes |
|---|
| go-redis | Shared distributed cache | You don't want network latency | The standard choice for cross-instance caching |
| Ristretto | Fast in-process cache | You need cache shared across servers | Excellent hit rate and throughput |
| Groupcache | Peer-to-peer distributed caching | You need explicit cache writes/invalidation | Great for immutable-ish data |
| BigCache / FreeCache | Simple in-memory caching | You want admission/eviction intelligence | Lower overhead, simpler behavior |
If you have multiple service instances
This is the most common deployment.
┌─────────────┐
│ Load Balancer│
└──────┬──────┘
│
┌────────────┼────────────┐
│ │ │
┌───▼───┐ ┌────▼───┐ ┌────▼───┐
│ App 1 │ │ App 2 │ │ App 3 │
└───┬───┘ └────┬───┘ └────┬───┘
│ │ │
└────────────┼────────────┘
│
Redis Cache
│
PostgreSQL
I'd recommend:
- Redis for the shared cache
- go-redis as the client
- Optional local cache (Ristretto) in front of Redis
This gives:
- cache shared across instances
- easy invalidation
- survives application restarts
- simple operations
This is by far the most common architecture.
If latency is critical
Use a two-level cache.
Request
│
Ristretto
│ miss
Redis
│ miss
Database
Benefits:
- local cache: ~100 ns–1 µs
- Redis: ~0.2–1 ms
- DB: 5–100+ ms
The local cache absorbs hot keys while Redis keeps all instances consistent enough.
When Ristretto shines
Ristretto is probably the best Go in-process cache today if:
- millions of keys
- skewed access patterns
- memory efficiency matters
- high concurrency
It uses:
- TinyLFU admission
- sample-based eviction
- batching to reduce contention
Compared with a plain LRU cache, hit rate is often noticeably better under real workloads.
Example:
cache, _ := ristretto.NewCache(&ristretto.Config{
NumCounters: 1e7,
MaxCost: 1 << 30, // 1 GB
BufferItems: 64,
})
It's a great local cache.
When Groupcache makes sense
Groupcache is a different philosophy.
Instead of:
miss -> Redis
you get:
miss
│
other peer?
│
database
Each key has an owner.
Advantages:
- avoids duplicate work
- automatic request coalescing
- no Redis required
- excellent for read-mostly datasets
Disadvantages:
- no explicit delete API
- assumes data changes infrequently
- operational model is different
- less flexible than Redis
Good examples:
- compiled templates
- user profiles
- metadata
- configuration
- package indexes
Less good for:
- shopping carts
- sessions
- rapidly changing objects
Handling cache stampedes
Whatever cache you choose, prevent this:
1000 requests
│
cache miss
│
1000 DB queries
Use request coalescing.
The standard library provides:
golang.org/x/sync/singleflight
value, err, _ := g.Do(key, func() (any, error) {
return loadFromDB()
})
This is valuable even if you're using Redis.
Cache invalidation
For mutable data:
Update DB
│
Delete Redis key
instead of trying to update cached values.
This is the common "cache-aside" pattern.
What I would use today
Small service
App
└── Redis
Simple and reliable.
Medium service
App
├── Ristretto
└── Redis
This is an excellent balance of latency, scalability, and operational simplicity.
Very large read-heavy service
App
├── Ristretto
├── Redis Cluster
└── singleflight
Add:
- background refresh for hot keys
- jittered TTLs to avoid synchronized expiration
- metrics (hit ratio, evictions, latency)
- negative caching for "not found" results
This architecture scales well to high QPS.
What I would not choose
I generally wouldn't start a new project with Groupcache unless its ownership model is exactly what you want (mostly immutable data and no need for explicit invalidation). While it's a clever design, most teams find Redis-based architectures easier to operate and integrate with other systems.
Overall recommendation
For a modern, high-read Go service, I'd recommend:
- Distributed cache:
go-redis with Redis (or Redis Cluster if needed).
- Local L1 cache: Ristretto if you have very hot keys or want to reduce Redis load.
- Stampede protection:
golang.org/x/sync/singleflight.
- Pattern: Cache-aside with TTLs, jittered expirations, and explicit invalidation on writes.
That combination is widely used, scales well, and gives you flexibility as your service grows.
If you can share your approximate workload (QPS, read/write ratio, object sizes, number of application instances, and whether data is mutable), I can recommend a more specific architecture and tuning strategy.
