Go Caching with Redis: The Latency Mirror

Redis caching in Go stores frequently accessed data in Redis — an in-memory data store — so your server can return results in under a millisecond without hitting the database. The standard approach is the Cache Aside pattern: check Redis first, fall back to the database on a miss, then store the result in Redis for future requests. Using the go-redis client library, you can implement this in a Go handler in under 20 lines of code.

Every time a user visits your "Top Tasks" page, your Go server queries the database. As your user base grows from ten to ten thousand, these repeated database hits will slow down your API and eventually crash your database.

The solution is Caching. By storing frequently accessed data in a fast, in-memory store like Redis, you can serve requests in milliseconds rather than seconds.

Redis is an open-source, in-memory data structure store. Because it keeps all its data in RAM (rather than on a slow spinning disk), it can handle hundreds of thousands of operations per second with sub-millisecond latency.

1. The Latency Mirror: Database vs. RAM Physics

To understand why we cache, we must look at the Physical Distance of data.

The Access Physics

• The DB Mirror (Disk): Even with SSDs, a database query requires the OS to traverse file system headers, handle locking, and physical read-head operations (millisecond scale).
• The Redis Mirror (RAM): Redis operations happen at the speed of an electrical signal traversing the CPU's memory bus (nanosecond/microsecond scale).
• The Network Cost: However, Redis is usually an external service. A cache hit includes a network round-trip. Go developers must balance the In-Process Mirror (fastest) against the Distributed Redis Mirror (sharable across 1,000 servers).

2. Connecting Go to Redis

The most popular Go client for Redis is go-redis. It's robust, well-maintained, and easy to use.

import "github.com/go-redis/redis/v8"

func main() {
    rdb := redis.NewClient(&redis.Options{
        Addr:     "localhost:6379",
        Password: "", // No password set
        DB:       0,  // Use default DB
    })

    // Ping the server to test the connection
    err := rdb.Ping(ctx).Err()
}

3. The TTL Geometry: TTL vs. Persistence

Time-to-Live (TTL) is the "Eviction Physics" that keeps the cache mirror from becoming an expensive memory dump.

The Freshness Physics

• TTL Geometry: A short TTL (10 seconds) creates a "Volatile Mirror" that stays fresh but puts more pressure on the DB. A long TTL (24 hours) minimizes DB load but risks desynchronization with the source of truth.
• Eviction Mirroring: When RAM fills up, Redis enters Eviction Physics (e.g., LRU - Least Recently Used). Go developers must monitor the "Evicted Keys" metric to ensure the cache isn't collapsing under its own weight.

4. The Cache Aside Pattern

The "Cache Aside" pattern is the industry standard for web applications.

1. When a request comes in, check Redis first.
2. If the data is in Redis (a Cache Hit), return it immediately.
3. If not (a Cache Miss), query the database, store the result in Redis, and then return it to the user.

func (h *TaskHandler) GetTopTasks(w http.ResponseWriter, r *http.Request) {
    // 1. Check Redis first
    val, err := h.rdb.Get(ctx, "top_tasks").Result()
    if err == nil {
        // Cache Hit! Send the string directly
        fmt.Fprint(w, val)
        return
    }

    // 2. Cache Miss! Query the database
    tasks := h.repo.GetTop()
    
    // 3. Store in Redis for next time (expires in 10 minutes)
    data, _ := json.Marshal(tasks)
    h.rdb.Set(ctx, "top_tasks", data, 10 * time.Minute)

    fmt.Fprint(w, string(data))
}

Cache Invalidation: The Hard Part

Cache invalidation — knowing when to remove stale data from the cache — is widely considered one of the hardest problems in computer science. There are two primary strategies:

1. TTL-Based Expiry (Passive Invalidation)

Set a Time-To-Live on every key. When the TTL expires, Redis automatically removes the key. The next request after expiry will be a cache miss, triggering a fresh database query.

This is the simplest approach and is appropriate when slightly stale data is acceptable — for example, a leaderboard that updates every 60 seconds is fine with a 60-second TTL.

2. Event-Driven Invalidation (Active Invalidation)

When a record is updated or deleted, explicitly remove or update its cache key:

func (h *TaskHandler) UpdateTask(w http.ResponseWriter, r *http.Request) {
    taskID := chi.URLParam(r, "id")
    
    // 1. Update the database
    h.repo.Update(taskID, newData)
    
    // 2. Immediately invalidate the cache
    h.rdb.Del(ctx, "task_"+taskID)
    h.rdb.Del(ctx, "top_tasks") // Also invalidate list caches
    
    w.WriteHeader(http.StatusOK)
}

Active invalidation keeps the cache fresh in real time but adds complexity. You must ensure every write path invalidates the correct keys — missing one means users see stale data.

Structuring Redis Keys Effectively

As your application grows, key naming becomes critical for maintainability and avoiding collisions. Use a consistent namespace convention:

// Pattern: {service}:{resource}:{id}:{variant}
"tasks:user:1001:top10"   // Top 10 tasks for user 1001
"tasks:summary:all"        // Global task summary
"users:profile:42"         // User profile for ID 42
"sessions:token:abc123"    // Session token lookup

This naming scheme makes it easy to:

• Flush all tasks-related cache keys in one go using SCAN + DEL with a pattern.
• Understand the cache contents when debugging without guesswork.
• Avoid two different parts of the application accidentally overwriting each other's keys.

Setting Up Redis for Local Development

If you have Docker installed, spinning up a local Redis instance takes one command:

docker run -d -p 6379:6379 --name go-redis redis:alpine

You can then connect your Go application to localhost:6379. To inspect the cache contents interactively, use the Redis CLI:

docker exec -it go-redis redis-cli
127.0.0.1:6379> KEYS *
127.0.0.1:6379> GET top_tasks
127.0.0.1:6379> TTL top_tasks

For production deployments, managed Redis services like AWS ElastiCache, Redis Cloud, and Upstash eliminate the operational overhead of running Redis yourself.

Measuring Cache Effectiveness

A cache that rarely gets hits is wasting memory and adding complexity for no benefit. Monitor these two key metrics:

• Cache Hit Rate = (cache hits / total requests) × 100. A healthy API cache should achieve 70–90% hit rate on eligible endpoints.
• Cache Miss Latency — the time spent on the database query when the cache misses. Ensure this is acceptable even without the cache.

You can track hits and misses by incrementing Redis counters in your handler:

val, err := h.rdb.Get(ctx, cacheKey).Result()
if err == redis.Nil {
    // Cache miss
    h.rdb.Incr(ctx, "metrics:cache_misses")
    // ... query database
} else if err == nil {
    // Cache hit
    h.rdb.Incr(ctx, "metrics:cache_hits")
}

Phase 22: Caching Architecture Mastery Checklist

• Verify TTL Sovereignty: Ensure that every SET operation includes a non-zero TTL. Orphan keys without expiry are the #1 cause of the "RAM Collapse" mirror.
• Audit Serialization Choice: Identify if JSON reflection is the bottleneck. For high-throughput caching, switch to Protobuf or MsgPack to reduce the marshalling mirror's CPU cost.
• Implement Sovereign Failover: If Redis is unreachable, ensure the code "Fails Soft" to the database. Never let a cache failure crash the request mirror.
• Test Cache Stampede Resistance: Use singleflight for hot keys (e.g., homepage data) to prevent the "Thundering Herd" from crushing the database on cache expiry.
• Use Semantic Key Namespacing: Follow the {service}:{resource}:{id} standard to ensure no key collisions occur in shared Redis environments.

Read next: Go Deployment & Docker: The Artifact Mirror →

Internal Links & Further Reading

For the broader context of this caching module, see the full Go REST API project guide and the Go deployment with Docker and CI/CD tutorial — the next step after optimising performance is shipping reliably. For security considerations when building Go backends, see Go security best practices.

External resources:

• Redis Caching Patterns — official Redis documentation
• go-redis v9 package documentation

Next Steps

Caching is a massive step toward building production-grade systems. But how do you actually get your code into the hands of real users? In our final phase, we will explore Deployment, learning how to package your Go application using Docker and ship it using modern CI/CD pipelines.

Common Redis Caching Mistakes in Go

1. Not setting a TTL on every key Keys without an expiry live forever. A cache that never evicts stale data becomes a memory leak and serves incorrect data. Always call SET key value EX seconds or use client.Set(ctx, key, value, ttl) with a non-zero TTL.

2. Cache stampede on cold start When a cached value expires, many concurrent requests may all miss the cache simultaneously and hammer the database. Use a single-flight pattern (golang.org/x/sync/singleflight) to ensure only one request fetches the value while others wait.

3. Caching errors If a database call fails, do not cache the error response. Only cache successful results. Caching a 500 error or an empty result means all users see the failure until the TTL expires.

4. Not handling Redis unavailability Redis is an external dependency — it can go down. Always have a fallback path: if the cache is unavailable, fall through to the database. Never make your application entirely dependent on Redis availability.

5. Using string keys without namespacing SET user 123 in a shared Redis instance collides with any other service using the same key. Always namespace keys: myapp:users:123. The Redis documentation on key naming covers conventions.

Frequently Asked Questions

Which Go Redis client should I use? go-redis is the most feature-complete client with support for Redis Cluster, Sentinel, and pipelining. rueidis is a newer, faster alternative with client-side caching support. Both are production-grade choices.

What is the Cache Aside pattern? Cache Aside (also called Lazy Loading) is the most common caching pattern: read from cache first; on a miss, read from the database, write the result to cache, then return it. The application code manages the cache explicitly rather than a transparent caching layer.

When should I use Redis vs an in-memory cache like sync.Map? Use sync.Map or a local cache (e.g. github.com/patrickmn/go-cache) for single-instance applications where the cache is local to the process. Use Redis when you have multiple application instances that need to share cached data, or when you need cache persistence across restarts.