Redis Production Best Practices
A Redis server that works on a laptop needs extra care before it serves real customers. Production best practices cover memory, safety, availability, data design, and daily operations. Following a checklist prevents the most common outages.
The Airplane Checklist Analogy
Pilots run through a written checklist before every flight, even after thousands of flights. The checklist catches small mistakes before they grow. A Redis launch checklist plays the same role. Each item closes one known risk.
Production Redis Layers ┌──────────────────────────────────────────┐ │ 4. Operations monitoring, backups │ ├──────────────────────────────────────────┤ │ 3. Data design key names, TTLs, sizes │ ├──────────────────────────────────────────┤ │ 2. Availability replicas, Sentinel │ ├──────────────────────────────────────────┤ │ 1. Foundation memory, network, security│ └──────────────────────────────────────────┘
Layer 1: Foundation
Memory
- Set maxmemory and choose an eviction policy.
- Leave at least 30 to 50 percent of system RAM free for snapshots and buffers.
- Turn off swap for the Redis host, or keep it very small.
Network and Security
- Bind Redis to private addresses only.
- Never expose port 6379 to the public internet.
- Create ACL users with minimum rights and disable the default user.
- Enable TLS when traffic crosses networks you do not control.
- Rename or block dangerous commands such as FLUSHALL for application users.
Layer 2: Availability
- Run at least one replica for every main server.
- Add three Sentinels on separate machines for automatic failover, or use Redis Cluster for sharded data.
- Choose a persistence mode that matches your data value. Use RDB for caches and RDB plus AOF for important data.
- Spread servers across more than one rack or zone.
Layer 3: Data Design
Practice Reason ───────────────────────── ─────────────────────────────────────── Use clear key names Faster debugging, easier cleanup Add a TTL to cache keys Memory never fills with stale data Keep values small Avoids slow commands and big replication Split big collections Prevents one key from blocking the server Use hashes for objects Saves memory against many string keys Avoid KEYS in app code Prevents freezes
Layer 4: Operations
Monitoring
Watch these numbers and alert on trouble.
Metric Alert When ─────────────────────────── ─────────────────────────────── used_memory Above 80 percent of maxmemory connected_clients Near the maxclients limit evicted_keys Rising fast on a data store rejected_connections Above zero master_link_status Not "up" on a replica latest slowlog entries New entries above 10 ms
Backups
Schedule daily backups, copy them off the server, and practice a restore every month.
Upgrades
Test every new Redis version on a staging server. Upgrade replicas first, switch roles, and upgrade the old main server last.
Client-Side Habits
- Use connection pools with sensible limits.
- Set connect and read timeouts so a slow server never hangs the app.
- Retry failed commands with a short, growing delay.
- Handle a cache miss gracefully by reading from the main database.
Practical Example – Launch Review for a Booking Site
Item Status ──────────────────────────── ─────── maxmemory 4gb + allkeys-lru Done Bind to private IP Done ACL users for app and admin Done 1 replica + 3 Sentinels Done Daily backup to cloud store Done Alerts on memory and latency Done Load test with real traffic Done All items checked → the team approves the launch.
Common Production Mistakes
- Running without a memory limit and meeting the operating system out-of-memory killer.
- Leaving the default user open on a reachable network.
- Storing cache keys without expiry.
- Skipping restore tests until a real emergency.
Key Points
- Work through memory, security, availability, data design, and operations.
- Replicas plus Sentinel or Cluster remove single points of failure.
- TTLs, small keys, and clear names keep data healthy.
- Monitoring and tested backups turn problems into short events.