Best Practices

The cache is in the critical path. A cache outage often looks like a database outage (when traffic falls through to the DB it can't handle). Treat the cache like one of your databases — redundant, observed, capacity-planned.

HA Topology

For Redis, three production modes:

Sizing:

• 3 nodes minimum for cluster mode (odd quorum).
• One replica per primary at minimum; two for critical workloads.
• Spread across availability zones.
• Sentinel quorum of 3 or 5 if not running Cluster.

Sizing and Eviction

Redis memory is finite. Decide what happens when it fills up:

# redis.conf
maxmemory 8gb
maxmemory-policy allkeys-lru

Wrong choice can be catastrophic. noeviction on a cache fills up and starts rejecting writes — your application sees errors instead of cache misses. Pick allkeys-lru or allkeys-lfu for typical cache use.

Memory Headroom

Keep used memory under ~75% of maxmemory. Above that, performance degrades sharply as the LRU sampling has to work harder. Capacity plan with growth in mind.

Persistence (Or Not)

Two options, both can be on simultaneously:

For a pure cache, persistence is optional — losing the cache means a slow warm-up but no data loss. For Redis as a primary store, use AOF with appendfsync everysec.

Naming Conventions

A namespace scheme saves you when debugging:

<domain>:<entity>:<id>[:<aspect>]

user:profile:42
user:session:abc-123
order:cart:42
auth:token:xyz
metrics:hourly:2026-05-21-14

• Colon-separated, by convention.
• Predictable prefixes make SCAN-based inspection useful.
• Versions in keys avoid invalidation pain (user:profile:42:v3).
• Don't put TTL or expiry in the key name — that's metadata for Redis, not you.

Observability

A cache without visibility is a hidden bottleneck. Watch:

The Redis exporter for Prometheus ships all of these. Hook into your existing dashboards.

Pitfalls and How to Avoid Them

Security

• TLS between clients and Redis (tls-port, tls-cert-file, tls-key-file).
• requirepass (or, better, ACL users in Redis 6+).
• Bind to internal interfaces only (bind 10.0.0.5), never public IPs.
• Disable dangerous commands in production: rename-command FLUSHALL "", same for KEYS, DEBUG, CONFIG.
• Per-environment instances — don't share Redis between staging and production "for cost."

Connection Management

Redis connections are cheap to keep, expensive to churn:

Multi-Region / Geo

Redis is not geo-distributed by default. Strategies:

• Active/passive with replication across regions; failover on outage.
• Per-region independent caches (recommended) — accept the "warm-up" cost over the complexity of cross-region writes.
• Active/active via Redis Enterprise CRDTs; complex; usually not worth it for a cache.

If you need active/active state, that's a job for a real database, not Redis.

When to Reach for Something Else

• Local memoization (in-process LRU like lru-cache) is faster than Redis for hot data shared only within one process.
• Two-tier cache: in-process LRU in front of Redis covers the very hottest keys.
• Search workloads belong in Search systems, not Redis.
• Pub/sub at scale — Redis Pub/Sub doesn't persist; use Message Queues.
• Vector / ANN — Redis has a vector module, but dedicated vector DBs (pgvector, Qdrant, Weaviate) are usually better.

Checklist