Redis client and connection guidance covering connection pooling, multiplexing, pipelining, client-side caching with RESP3, avoiding slow commands (KEYS, SMEMBERS, HGETALL), and tuning socket timeouts. Use when configuring a Redis client (redis-py, Jedis, Lettuce, NRedisStack), batching commands for

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 See [references/pooling.md](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. 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](references/pipelining.md). 3. Avoid commands that scan everything Anything that walks the whole keyspace (or a whole large container) blocks the server. Use incremental variants instead. Don't Use KEYS pattern SCAN cursor loop SMEMBERS large set SSCAN HGETALL large hash HSCAN LRANGE 0 1 on a huge list Paginate ( LRANGE 0 100 ) Blocking commands ( BLPOP , BRPOP , BLMOVE ) are different — they intentionally wait for data and are fine for queue consumers, but always pass a timeout, and don't issue them on a multiplexed connection (Lettuce, NRedisStack). See [references/blocking.md](references/blocking.md). 4. Client side caching for hot keys For data that's read often and written rarely (config, feature flags, sessions on every request), enable RESP3 client side caching. The client keeps a local copy and the server invalidates it on writes — saving the round trip for hot reads. Skip it for write heavy workloads or data that changes constantly — the invalidation traffic overruns the savings. See [references/client cache.md](references/client cache.md). 5. Set explicit timeouts Defaults vary by client and may be too generous. Pick values that match the application's failure model: Rule of thumb: connect timeout shorter than read/write timeout. Tight timeouts + retry on timeout for latency sensitive paths; longer timeouts for batch jobs. See [references/timeouts.md](references/timeouts.md). References [Redis: Connection Pools and Multiplexing](https://redis.io/docs/latest/develop/clients/pools and muxing/) [Redis: Pipelining](https://redis.io/docs/latest/develop/use/pipelining/) [Redis: SCAN](https://redis.io/docs/latest/commands/scan/) [Redis: Client side caching](https://redis.io/docs/latest/develop/clients/client side caching/) [Redis: Clients](https://redis.io/docs/latest/develop/clients/)

redis-connections