Redis Anti-Patterns: Common Mistakes Every Developer Should Avoid

- **Large databases on a single shard** — keep shards under 25 GB or 25K ops/sec > - **Direct connections without a proxy** — use a connection proxy to prevent reconnect floods > - **Caching keys without TTL** — always set expiration on cache keys to prevent unbounded growth > - **Hot keys** — distribute frequently accessed data across multiple shards > - **Using the KEYS command** — use `SCAN` or Redis Search instead > - **Storing JSON blobs in strings** — use HASH structures or Redis JSON > - **Running ephemeral Redis as a primary database** — enable persistence and high availability > - **Endless replication loops** — tune replica and client buffers for large active databases Devs don't just use Redis, they love it. ... - How to identify the most critical Redis anti-patterns in your application - Why single-shard deployments and direct connections cause reliability problems - The performance impact of missing TTLs, hot keys, and the `KEYS` command - Best practices for data modeling with HASH structures and Redis JSON ... ## # Anti-pattern summary |#|Anti-pattern|Severity|Impact| |--|--|--|--| |1|Large database on a single shard|High|Slow failover, long backup/recovery| |2|Connecting directly to Redis instances|High|Reconnect floods, forced failovers| |3|Incorrect replica count (open source)|Medium|Split-brain risk| |4|Serial single operations (no pipelining)|Medium|Increased latency, wasted round-trips| |5|Caching keys without TTL|High|Unbounded memory growth, eviction storms| |6|Endless replication loop|Medium|Replication never completes| |7|Hot keys|High|Single-node bottleneck in clusters| |8|Using the KEYS command|High|Blocks Redis, O(N) full scan| |9|Ephemeral Redis as primary database|High|Data loss, downtime on restart| |10|Storing JSON blobs in strings|Medium|Expensive parsing, no atomic field updates| |11|HASH without considering query patterns|Medium|Limited filtering, full scans required| … ## # 1. Large databases running on a single shard/Redis instance **What is the single-shard anti-pattern?** Running a large dataset on one Redis instance means that failover, backup, and recovery all take significantly longer. If that single instance goes down, the blast radius covers your entire dataset. With large databases running on a single shard/Redis instance, there are chances that the fail over, backup and recovery all will take longer. Hence, it's always recommended to keep shards to recommended sizes. General conservative rule of thumb is 25Gb or 25K Ops/Second. … ## # 2. Connecting directly to Redis instances **What is the direct-connection anti-pattern?** When many clients connect directly to Redis without a proxy, a reconnect flood after a network hiccup can overwhelm the single-threaded Redis process and force a failover. With many clients, a reconnect flood will be able to simply overwhelm a single threaded Redis process and force a failover. … ## # 5. Caching keys without TTL **What is the missing-TTL anti-pattern?** Storing cache keys without an expiration means they accumulate indefinitely. Over time this leads to unbounded memory growth, increased eviction pressure, and potentially out-of-memory errors. Redis functions primarily as a key-value store. It is possible to set timeout values on these keys. … ## # 9. Running Ephemeral Redis as a primary database **What is the ephemeral-primary anti-pattern?** Using Redis as your application's primary database without enabling persistence or high availability means a restart results in complete data loss, and any downtime takes your entire application offline. Redis is often used as a primary storage engine for applications. Unlike using Redis as a cache, using Redis as a primary database requires two extra features to be effective.