13 Redis Best Practices to Save Memory, Boost Performance, Ensure Reliability

Memory Optimization

Redis stores all data in memory, which makes it fast but also expensive; as data grows, memory can balloon quickly. To keep memory usage low, control key length (e.g., use short prefixes like u:bk:123 instead of user:book:123), avoid big values (keep strings under 10 KB, collections under 10 k elements), and choose appropriate data types that use compact encodings such as integer encoding for small numbers or ziplist for small hashes and sorted sets.

Treat Redis as a cache rather than a primary datastore: set expiration times for most keys so that only hot data stays in memory. Configure maxmemory and select an eviction policy that matches your workload (e.g., volatile-lru, allkeys-lru, volatile-lfu, allkeys-lfu, volatile-ttl, volatile-random, allkeys-random).

Compress data before writing to Redis (e.g., using Snappy or gzip) when further memory savings are needed, bearing in mind the extra CPU cost for decompression.

Performance Tuning

Redis can handle up to 100 k QPS on a single instance, but large keys and high‑complexity commands can cause latency spikes. Avoid storing big keys; if unavoidable, enable the lazy‑free mechanism (Redis 4.0+) so that memory release runs in background threads.

Avoid commands with high time complexity (e.g., SORT, SINTER, ZUNIONSTORE) or O(N) commands on large collections without pagination. Instead, query collection size first ( LLEN, HLEN, SCARD, ZCARD) and then fetch data in batches using LRANGE, HSCAN, SSCAN, ZSCAN.

Use batch commands (e.g., MGET / MSET for strings, pipelines for other types) to reduce round‑trip latency. Deploy read‑only replicas and sharded clusters when read or write traffic is high, and keep the number of replicas odd for Sentinel elections.

Configure maxmemory before scaling; increase it on replicas first, then on the master, and decrease it on the master first, then on replicas, to avoid unintended data eviction.

Reliability and High Availability

Isolate workloads by deploying separate Redis instances per business line, reducing blast‑radius of failures. Use master‑slave replication (or Redis Cluster) to avoid single‑point‑of‑failure; ensure replicas run on different machines and are configured as read‑only.

Fine‑tune replication parameters: set an adequate repl-backlog size to prevent full syncs under heavy write loads, and adjust slave‑client-output-buffer-limit to avoid replica buffer overflow.

Deploy Sentinel clusters with an odd number of nodes distributed across machines to enable automatic failover.

Daily Operations

Never run KEYS, FLUSHALL, or FLUSHDB in production; replace KEYS with SCAN and use asynchronous flushes ( FLUSHALL ASYNC) on Redis 4.0+. When scanning, add sleep intervals to avoid high OPS spikes.

Use MONITOR sparingly, as it can consume memory and increase latency on busy instances.

Keep replicas read‑only; older Redis versions (<4.0) have a bug where expired keys on replicas are not freed, leading to memory leaks.

Configure reasonable timeout and enable tcp‑keepalive so that dead client connections are reclaimed promptly.

When adjusting maxmemory, modify replicas before masters when increasing, and the opposite when decreasing.

Security

Do not expose Redis to the public internet; change the default port, run the process as a non‑root user, restrict configuration file permissions, enable password authentication, and rename or disable dangerous commands ( KEYS, FLUSHALL, CONFIG, EVAL).

Resource Planning & Monitoring

Ensure sufficient CPU, memory, bandwidth, and disk capacity. Reserve at least half of the master’s memory for failover scenarios, and keep single‑instance memory under 10 GB to avoid blocking during full sync or RDB backup.

Monitor key metrics: expired_keys, evicted_keys, latest_fork_usec, and set alerts for sudden spikes. Configure appropriate slowlog thresholds and use long‑lived connections for INFO collection.

Prevention

Proactively plan resources and set up comprehensive alerting. Conduct capacity planning, keep instances below 10 GB, and monitor system health to catch issues before they impact users.

Summary

The article consolidates Redis best practices across seven dimensions—memory, performance, reliability, daily operations, resource planning, monitoring, and security—providing actionable recommendations for both developers and DBA/operations engineers. By following the mandatory, recommended, and optional guidelines, teams can achieve efficient, stable, and secure Redis deployments.