10 Essential Redis Best Practices Every Developer Should Follow

1. Stop Using KEYS *

Running KEYS * scans the entire keyspace with O(n) complexity, which can block the server for large datasets. Instead, use SCAN, which iterates incrementally using a cursor and can be paused or resumed at any time.

for key in 'keys *':
    doAllTheThings()

2. Identify Performance Bottlenecks with INFO commandstats

Redis lacks detailed logs, but the INFO commandstats command provides per‑command call counts and latency statistics.

127.0.0.1:6379> INFO commandstats
# Commandstats
cmdstat_get:calls=78,usec=608,usec_per_call=7.79
cmdstat_setex:calls=5,usec=71,usec_per_call=14.20
cmdstat_keys:calls=2,usec=42,usec_per_call=21.00
cmdstat_info:calls=10,usec=1931,usec_per_call=193.10

Reset the counters with CONFIG RESETSTAT to obtain a fresh snapshot.

3. Treat Redis‑Benchmark Results as Reference Only

Benchmark numbers depend on client environment, Redis version, and how closely the test mirrors production workloads. Use them as a baseline, not as a definitive stress‑test.

What client runtime limitations exist?

Is the same Redis version used?

Does the test environment match the production environment?

4. Use Hashes Instead of Many Separate Keys

Storing related fields in a hash reduces key count and simplifies access.

# Bad practice – many keys
foo:first_name
foo:last_name
foo:address

# Better – a single hash
127.0.0.1:6379> HSET foo first_name 'Joe'
127.0.0.1:6379> HSET foo last_name 'Engel'
127.0.0.1:6379> HSET foo address '1 Fanatical Pl'
127.0.0.1:6379> HGETALL foo
1) 'first_name'
2) 'Joe'
3) 'last_name'
4) 'Engel'
5) 'address'
6) '1 Fanatical Pl'

5. Set Expiration (TTL) on Keys

Give temporary data—such as authentication tokens—a time‑to‑live so Redis automatically removes them, avoiding the need to scan with KEYS *.

6. Choose an Appropriate Eviction Policy

When memory fills up, Redis evicts keys based on the configured policy. Use volatile‑lru for keys that have an expiration, or allkeys‑lru for cache‑like data without TTLs.

7. Guard Critical Writes with Try/Except

Because many Redis clients use a fire‑and‑forget approach, wrap important writes in a try/except block to verify that the operation succeeded.

8. Distribute Load Across Multiple Instances

From Redis 3.0 onward, clustering lets you shard data by key range across master/replica nodes. If clustering isn’t an option, use logical namespaces to spread keys among several instances.

9. More CPU Cores Do Not Speed Up a Single Instance

Redis is single‑threaded; it typically uses only one core (plus a second for persistence). Running multiple instances on the same machine is only useful for development or isolation, not for performance gains.

10. Ensure High Availability with Sentinel

Redis Sentinel provides robust monitoring, automatic failover, and configuration updates. Deploy Sentinel in production to keep your Redis service online even when individual nodes fail.