10 Essential Redis Best Practices Every Developer Should Follow

Redis is a popular in‑memory data store that has become an industry standard, and a set of best practices helps users employ it correctly.

Below are ten practical tips for using Redis effectively.

1. Stop using KEYS *

Running KEYS * on large datasets is slow because its time complexity is O(n) and blocks other commands. Instead, use SCAN, which iterates incrementally with a cursor and can be paused or resumed.

for key in 'keys *':
    doAllTheThings()

2. Identify the root cause of Redis slowdowns

Redis provides the INFO commandstats command to view per‑command call counts and latency. Reset statistics with CONFIG RESETSTAT to obtain a fresh snapshot.

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

3. Treat Redis‑Benchmark results as a reference only

Benchmark numbers depend on client environment, Redis version, and test conditions. Use them as a sanity check, not as a definitive stress test; a realistic load test should mimic production behavior.

What client runtime constraints exist?

Are the versions identical?

Does the test environment match the production environment?

4. Use hashes instead of many separate keys

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

foo:first_name
foo:last_name
foo:address

Replace with:

127.0.0.1:6379> HSET foo first_name 'Joe'
(integer) 1
127.0.0.1:6379> HSET foo last_name 'Engel'
(integer) 1
127.0.0.1:6379> HSET foo address '1 Fanatical Pl'
(integer) 1
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 an expiration for keys when appropriate

Use key TTLs for temporary data such as OAuth tokens; Redis will automatically delete expired keys, eliminating the need for manual scans.

6. Choose the right eviction policy

If the dataset fills memory, select volatile-lru when keys have expirations, or allkeys-lru for cache‑like workloads without TTLs.

7. Wrap critical writes in try/except blocks

Because most Redis clients use a fire‑and‑forget approach, catching exceptions ensures that important data has been persisted.

8. Distribute load across multiple instances

Use Redis Cluster (available since 3.0.0) to shard data by key range, or employ namespaces and multiple instances if clustering is not an option.

9. More CPU cores do not improve a single Redis instance

Redis is single‑threaded; even with persistence it uses at most two cores. Running multiple instances on the same host only makes sense for development or testing.

10. Ensure high availability

Redis Sentinel has been widely tested and is used in production. For managed solutions, consider services that provide 24/7 support and built‑in HA.