Caching with Redis

Cache-aside: the default pattern

Redis is an in-memory key–value store — data lives in RAM, so reads and writes are sub-millisecond — commonly used as a cache in front of a slower database (and also for sessions, rate limiters, and queues); learn it at redis.io. The most common caching pattern is cache-aside (lazy loading): the app checks the cache, and on a miss loads from the database and populates the cache.

graph TD
R["read(key)"] --> C{"in cache?"}
C -->|hit| RET["return cached value (fast)"]
C -->|miss| DB["load from database"]
DB --> SET["store in cache with TTL"]
SET --> RET
W["write(key)"] --> WDB["write to database"]
WDB --> INV["delete cache key (invalidate)"]

The cache fills on demand with hot data; the database stays the source of truth. The app owns two responsibilities: read-through (populate on miss) and invalidation (clear on write).

See it: cache-aside with hit/miss accounting

This runs here — an in-memory cache-aside layer that loads from a “database” only on a miss, then serves hits without touching it. Output is deterministic:

package main

import "fmt"

type Cache struct {
data map[string]string
}

var dbReads int // count expensive backend loads

func loadFromDB(key string) string {
dbReads++
return "value-of-" + key
}

func (c *Cache) Get(key string) string {
if v, ok := c.data[key]; ok {
	return v // cache hit — no DB read
}
v := loadFromDB(key) // miss → load and populate
c.data[key] = v
return v
}

func (c *Cache) Invalidate(key string) { delete(c.data, key) }

func main() {
c := &Cache{data: map[string]string{}}

c.Get("user:1") // miss → DB read
c.Get("user:1") // hit
c.Get("user:1") // hit
c.Get("user:2") // miss → DB read
fmt.Println("DB reads:", dbReads) // 2, not 4

// A write invalidates, so the next read reloads fresh data.
c.Invalidate("user:1")
c.Get("user:1") // miss → DB read
fmt.Println("DB reads after write:", dbReads) // 3
}

Four reads of two keys cost only two DB loads; the rest are cache hits. Invalidation on write forces a fresh reload. The real Redis client is the same shape (fenced — third-party):

// Fenced: github.com/redis/go-redis/v9
val, err := rdb.Get(ctx, key).Result()
if err == redis.Nil { // miss
	val = loadFromDB(key)
	rdb.Set(ctx, key, val, 5*time.Minute) // store with a TTL
}
// on write: rdb.Del(ctx, key)

TTLs, stampedes, and invalidation

• TTL — every entry expires, bounding staleness and reclaiming memory. Pick it by how much staleness the data tolerates.
• Stampede — when a hot key expires, all concurrent requests miss and hit the database at once, a spike that can take it down. Prevent it with single-flight (coalesce concurrent misses so one request loads and the rest wait — golang.org/x/sync/singleflight), jittered TTLs (so keys don’t expire together), or proactive refresh.
• Invalidation — on a write, delete the key (write-DB-then-delete) so the next read repopulates. There’s no perfectly race-free invalidation, which is why the TTL backstop matters.

See also

• Message queues — invalidating caches via events across services.
• Resilience patterns — surviving a cache/datastore outage.
• database/sql & transactions — the source of truth behind the cache.
• Rate limiting (concurrency) — single-flight’s cousin for bounding load.

Next: building services that stay up when dependencies fail — resilience patterns.

Related topics