GopherForgeA WORKBENCH FOR GO

Around Go: MongoDB and Redis · 3 MIN READ

Redis: share the client and distinguish a miss from an outage

Configure go-redis deadlines, connection budgets and explicit cache-miss behavior.

Redis is often used as a low-latency data-structure service, but the network, client pool and command cost still exist. Create a shared client, keep a bounded operation context and distinguish redis.Nil from transport failures. A missing optional cache entry and an unavailable required store have different application contracts.

Around Go: data stores · A MAP OF THE IDEA

  1. Shared client
  2. Bounded operation
  3. Value / miss / failure
  4. Deliberate fallback

Useful when

  • Configure go-redis deadlines, connection budgets and explicit cache-miss behavior.

Watch out

  • redis.Nil from GET means this key is absent. A transport failure is a different result; unlimited fallback work during an outage can overwhelm the origin.

Implementation & operation cost: Shared pools save connection setup; their total size, retries and waiting must fit the deployment’s capacity budget.

01

Construct one client with explicit example budgets

This lesson uses github.com/redis/go-redis/v9 with v9.16.0 as an example pin. PoolSize and MaxActiveConns are distinct knobs; do not assume a pool’s preferred retained size is a universal hard ceiling. Confirm options against the pinned version rather than copying future-version defaults.

go
rdb := redis.NewClient(&redis.Options{
    Addr: addr, PoolSize: 16, MaxActiveConns: 16,
    PoolTimeout: 200*time.Millisecond,
    DialTimeout: time.Second, ReadTimeout: time.Second, WriteTimeout: time.Second,
    ContextTimeoutEnabled: true, MaxRetries: -1,
})
// One application owner closes rdb after in-flight work drains.
Read the code

The values illustrate a bounded small-client configuration, with automatic retries disabled so policy is visible. Production TLS, authentication and addresses come from configuration; re-enable suitable retries only with an overall operation budget and duplicate-effect analysis.

02

Handle absence explicitly

redis.Nil represents a missing key for a GET, not a dead server. Preserve other errors so a caller can apply the intended fallback or failure policy. A fallback that recomputes expensive data on every transport failure can overwhelm the primary database during a Redis outage.

go
value, err := rdb.Get(ctx, key).Result()
switch {
case errors.Is(err, redis.Nil):
    return loadFromOrigin(ctx, key)
case err != nil:
    return "", fmt.Errorf("cache read: %w", err)
default:
    return value, nil
}
Read the code

This is a helper returning string and error. The application supplies a bounded ctx and loadFromOrigin; the example deliberately surfaces infrastructure failure instead of silently starting unlimited origin requests.

03

Keep version and workload assumptions visible

Later client versions can change pooling and pipeline behavior. Pin and test the version used by the service, including cancellation and saturation. These native network examples are not executable Redis access inside the app’s WASI sandbox; they teach the surrounding Go service environment.

TAKE THIS WITH YOU

Reuse the client, configure bounded waiting and handle value, miss and outage separately. Fallback and retry behavior are application decisions, not invisible conveniences.

Check your understanding

How should a GET cache miss differ from a transport error?

Go to the source

Progress stays in this browser. No account needed.