redis-connections

Redis Connections

Client-side guidance for talking to Redis efficiently: how to share connections, how to batch commands, which commands not to call in production, when to turn on client-side caching, and how to set timeouts that fail fast without breaking healthy traffic.

When to apply

• Creating or reviewing a Redis client setup (redis-py, Jedis, Lettuce, go-redis, NRedisStack).
• Making many small Redis calls and wondering where the latency is going.
• Iterating large keyspaces, sets, hashes, or lists.
• Enabling client-side caching for hot keys.
• Tuning connect / read / write timeouts.

1. Pool or multiplex — never one connection per request

The single biggest mistake in Redis client code is opening a new TCP connection for every operation. Always either:

• Pool — keep N persistent connections that the application leases per call (redis-py ConnectionPool, Jedis JedisPooled, go-redis client).
• Multiplex — share a single connection across all requests (Lettuce, NRedisStack).

Style	Used by	Note
Pool	redis-py, Jedis, go-redis	Each lease blocks if pool exhausted; size the pool to your concurrency
Multiplex	Lettuce, NRedisStack	Single connection; cannot carry blocking commands like BLPOP

# redis-py — connection pool
pool = redis.ConnectionPool(host="localhost", port=6379, max_connections=50)
r = redis.Redis(connection_pool=pool)

See references/pooling.md for Python + Java + Lettuce examples.

2. Pipeline bulk work

For N commands that don't depend on each other's results, send them as a single batch with pipelining. One round-trip instead of N.

pipe = redis.pipeline()
for user_id in user_ids:
    pipe.get(f"user:{user_id}")
results = pipe.execute()

Use non-transactional pipelining for performance, and pipeline(transaction=True) only when you actually need atomicity (see redis-core's transactions guidance).

See references/pipelining.md.