Quick Answer: What are the most common mistakes when using redis in production?
The most common mistakes when using Redis in production are running blocking commands like KEYS on live data, letting memory grow without an eviction policy, and treating Redis as durable storage when persistence defaults can lose recent writes. Teams can fix most of these problems through configuration changes, command discipline, and monitoring. (Redis Documentation)
Related but different risks include hot keys, connection churn, and using pub/sub as a job queue. Each one behaves differently and needs its own fix, so a single “just add more memory” approach rarely works.
Before changing anything, teams should check their eviction policy, persistence settings, client connection limits, key size distribution, authentication setup, and failover configuration.
Redis answers millions of requests per second with sub-millisecond latency, which is exactly why so many teams reach for it. That speed is also why its failure modes are so sneaky. A misconfigured Redis instance does not usually crash loudly. It slows down, fills up, or silently drops data, and the first sign of trouble often shows up as a spike in application errors at 3 a.m.
The mistakes below are not exotic. They are the same handful of issues that show up again and again in postmortems, and most of them trace back to treating Redis like a general-purpose database instead of the specialized tool it is.
Running KEYS in Production and Other Blocking Commands
The `KEYS` command scans every key in the database in one pass. On a small dataset it feels harmless. On a production instance holding millions of keys, it can block the server for seconds. Because Redis executes commands largely on a single thread, everything else waits while that scan runs.
The documented alternative is `SCAN`, which walks the keyspace in small batches and lets other commands interleave. It is not a perfect drop-in replacement, since it offers weaker guarantees about completeness, but it will not freeze the server.
The same trap applies to other blocking operations. Long-running Lua scripts, `BLPOP` calls against a shared instance, and heavy `SORT` operations can all stall unrelated traffic. A useful habit is to run `SLOWLOG GET` regularly and treat any command above a few milliseconds as a candidate for redesign.
Ignoring Memory Limits and Eviction Policy
Many teams spin up Redis, never set `maxmemory`, and assume the operating system will handle it. It will, badly. Once memory runs out, the OS may kill the process, or the instance starts rejecting writes with out-of-memory errors.
The fix is to set an explicit `maxmemory` value and choose a policy that matches how the data is used. The choice matters more than most people expect:
| Policy | Behavior | Good fit |
|---|---|---|
| noeviction | Returns errors when memory is full | Data that must never be silently dropped |
| allkeys-lru | Evicts least recently used keys across all keys | Pure caches |
| volatile-lru | Evicts LRU keys only among those with a TTL | Mixed cache and persistent data |
| allkeys-lfu | Evicts least frequently used keys | Caches with stable hot sets |
| volatile-ttl | Evicts keys with the shortest remaining TTL | Short-lived session data |
A cache that quietly evicts keys it should have kept, or a session store that rejects writes at peak traffic, usually traces back to a policy that was never chosen on purpose. Pick one deliberately, document why, and revisit it when the workload changes.
Treating Redis as Durable Storage
Redis persistence is real, but it is not the same as a relational database’s write-ahead log. Snapshotting (RDB) saves the dataset at intervals, so a crash can lose everything written since the last snapshot. Append-only file (AOF) mode narrows that window, but the default fsync behavior still leaves a gap.
The practical rule: if losing the last few seconds of writes would break the business, Redis should not be the only copy. Use it as a fast layer in front of a durable store, or configure AOF with a stricter fsync policy and accept the throughput cost. Teams that skip this decision often discover it during their first real outage, which is the worst possible time to learn.
One Instance, No Failover
A single Redis instance is a single point of failure. When it goes down, every service that depends on it goes down too, often with a cascade of retries that makes the outage worse.
Redis Sentinel provides monitoring and automatic failover for a primary-replica setup. Redis Cluster shards data across nodes and adds failover at the shard level. Both add operational complexity, and both are worth it once Redis sits on a critical path. The mistake is not choosing a simple setup early on. The mistake is never revisiting that choice as the system grows into something Redis was not originally sized for. (Redis)
Hot Keys, Big Keys, and Uneven Load
Two keys can bring down a cluster that has plenty of capacity. A hot key absorbs a disproportionate share of traffic, so one shard maxes out while the others sit idle. A big key, such as a hash with millions of fields or a list that never gets trimmed, takes a long time to read, delete, or migrate.
Redis ships with tooling to find these: `redis-cli –bigkeys` surfaces oversized keys, and `–hotkeys` (with the right eviction policy) helps identify the most frequently accessed ones. Common fixes include splitting large collections, adding a local in-process cache in front of hot keys, and adding key prefixes so related data spreads across shards.
It is also worth checking key naming discipline. Screenshots, exports, and generated assets stored directly in Redis are a frequent source of bloat. If the workload involves image generation or design assets, a dedicated pipeline such as an AI mockup generator for product design or an AI product photography generator for ecommerce belongs in object storage, not in a Redis key.
Using Pub/Sub as a Job Queue
Pub/Sub is fire-and-forget. Messages are not persisted, there is no acknowledgment, and any subscriber that is offline when a message is published simply misses it. That is fine for cache invalidation broadcasts. It is not fine for order processing, email delivery, or anything where a lost message means a lost customer action.
Redis Streams, with consumer groups and acknowledgments, is a much better fit for queue-like workloads. For heavy-duty job processing, a dedicated message broker may be the right call. The key question is simple: if a message disappears, does anyone notice? If the answer is yes, pub/sub is the wrong tool.
Connection Churn and Missing Pooling
Every Redis connection costs memory on the server, and `maxclients` caps how many can exist at once. Applications that open a new connection per request burn through that budget quickly, especially under load or after a deploy when connection storms are common.
Connection pooling solves most of this. So does setting sane timeouts and making sure clients reconnect with backoff instead of hammering a recovering server. When a Redis instance restarts, a thousand clients retrying at once can knock it over again. Jittered backoff is not optional at scale.
Cache Stampedes and Missing TTL Jitter
When a popular key expires, every request that misses it goes to the database at the same moment. This cache stampede can overwhelm a backend that was comfortably handling traffic seconds earlier.
Two habits help. First, add random jitter to TTLs so keys do not all expire together. Second, use a lock or a “stale-while-revalidate” pattern so only one request rebuilds the value while others serve slightly stale data. Neither is complicated, but both require thinking about expiry before the incident, not during it.
Leaving the Instance Exposed
An unauthenticated Redis instance bound to a public interface is one of the fastest ways to end up in a breach. Attackers have automated scanners that look for exactly this. Redis ships with `protected-mode` enabled by default for good reason, and access control lists (ACLs) let you scope what each client can do.
Practical hardening steps include binding to private interfaces only, requiring authentication, disabling or renaming dangerous commands, and restricting network access with security groups or firewalls. None of this is glamorous, and all of it is cheaper than an incident response bill. For teams documenting their setup, capturing configuration screenshots for runbooks is worth the two minutes it takes to learn how to take a screenshot on a mac or how to take a screenshot on windows, so the evidence lives somewhere other than a departing engineer’s memory.
Skipping Monitoring and Slow Log Review
Redis exposes a rich set of metrics through `INFO`: memory usage, evicted keys, connected clients, hit rate, and command statistics. Teams that never look at them are flying blind. A cache hit rate that quietly drops from 95 percent to 60 percent is a slow-motion outage, and it is invisible without monitoring.
At minimum, alert on memory approaching `maxmemory`, rising evicted key counts, connected clients nearing `maxclients`, and replication lag. The slow log deserves a weekly glance. It is the single cheapest way to catch a bad command before it becomes an incident.
Version Drift and Configuration Assumptions
Redis has changed meaningfully over the years, including its licensing and default behaviors. Advice from a 2016 blog post may not apply to a current release, and defaults that once seemed safe have shifted. The reliable approach is to read the configuration file comments for the exact version in use, check release notes before upgrading, and avoid copying production configs between major versions without review.
This is a quiet mistake, but a common one. Assumptions age badly, and Redis configuration is full of them.
Conclusion
Almost every serious Redis incident traces back to a small set of decisions: a command that blocked the server, a memory limit nobody set, a durability assumption nobody tested, or a single instance nobody made redundant. None of these require deep expertise to fix. They require someone to look.
The pattern across all of them is the same. Redis rewards teams who treat it as a specialized, fast, in-memory tool with clear boundaries, and it punishes teams who treat it as a general-purpose database that happens to be quick. Audit the eviction policy, review the slow log, test a failover, and confirm what happens to data during a crash. That short list covers most of the ground.
Frequently Asked Questions
Is Redis fast enough to use as a primary database?
It is fast, but speed and durability are different questions. Redis persistence can lose recent writes depending on configuration, so it works best as a fast layer in front of a durable store rather than the only copy of critical data.
What should replace KEYS in production?
`SCAN` is the standard replacement. It iterates the keyspace in small batches instead of scanning everything at once, so it does not block other commands for extended periods.
How do I know if I have a hot key problem?
Look for latency spikes paired with uneven CPU usage across cluster nodes, or a single key dominating command statistics. The `–hotkeys` tool and per-key access monitoring can confirm it.
Does Redis Cluster eliminate the need for careful key design?
No. Cluster spreads keys across shards, but a single oversized key or a poorly distributed key pattern can still overload one shard while others idle. Key design matters more in a cluster, not less.
What is a reasonable maxmemory setting?
There is no universal number. Leave headroom for replication buffers, fragmentation, and background saves, then test under realistic load. Setting it to the full available RAM is a common and painful mistake.
Can I use Redis pub/sub for background jobs?
It works for fire-and-forget notifications but not for jobs that must not be lost. Pub/sub has no persistence or acknowledgment, so Redis Streams with consumer groups is the better choice for reliable processing.
