Common Redis Pitfalls and How to Avoid Them

In this article the author, Kaito, walks through a series of common pitfalls that developers encounter when using Redis and offers concrete ways to avoid or mitigate them.

1. Command‑related pitfalls

Unexpected expiration loss : Using SET key value EX 60 sets a TTL, but a subsequent SET key newvalue without the EX option erases the expiration, turning the key into a permanent entry.

127.0.0.1:6379> SET testkey val1 EX 60
OK
127.0.0.1:6379> TTL testkey
(integer) 59

127.0.0.1:6379> SET testkey val2
OK
127.0.0.1:6379> TTL testkey   // key never expires!
(integer) -1

To keep the TTL you must repeat the expiration parameter on every update.

DEL can block : Deleting a non‑String key (List/Hash/Set/ZSet) has O(M) complexity, where M is the number of elements, because Redis must free each element’s memory. Large collections or big‑keys can therefore block the server.

Check element count with LLEN, HLEN, SCARD, ZCARD.

If the count is small, delete directly; otherwise delete in batches using LRANGE/HSCAN/SSCAN/ZSCAN plus LPOP/RPOP/HDEL/SREM/ZREM.

RANDOMKEY may block : The command randomly picks a key, checks if it is expired, and if so deletes it (lazy deletion). When many keys are expired but not yet removed, the loop can become very long, especially on a slave that never deletes expired keys, potentially causing a dead‑loop.

2. Persistence pitfalls

Master crash without persistence : In a master‑slave + Sentinel setup where the master has no persistence enabled, a master crash followed by an automatic restart leaves the master empty; the slave then clears its data to stay consistent, causing total data loss.

AOF every‑second does not guarantee 1‑second data loss : If the background fsync is blocked by high disk I/O, the main thread may skip writing to the AOF page cache for up to 2 seconds, so a crash can lose up to 2 seconds of data.

RDB/AOF rewrite OOM : During RDB snapshots or AOF rewrite Redis forks a child process. Writes continue in the parent using copy‑on‑write, which can double memory usage. On a machine with limited RAM this can trigger OOM.

3. Master‑slave replication pitfalls

Data loss on async replication : If the master crashes before pending writes are replicated, those writes are lost. This is acceptable for pure caching but problematic for use‑cases like distributed locks.

Expired‑key visibility differences : Older Redis versions (≤3.2) let slaves return values for keys that are logically expired on the master. Versions 3.2‑4.0.11 still return true for EXISTS on expired keys. From 4.0.11 onward the bug is fully fixed.

Clock skew : Slave clocks that run faster than the master may consider keys expired earlier, causing inconsistent query results.

Memory‑limit mismatch : If master and slave have different maxmemory settings, the slave may start evicting keys earlier, leading to data inconsistency. Adjust the limits in the correct order (increase slave first, decrease master first) or enable replica-ignore-maxmemory (default yes in Redis 5.0) to prevent slave‑side eviction.

Slave memory leak (pre‑4.0) : Writable slaves ( read‑only=no) that store keys with TTL may retain expired keys forever, causing a leak. This was fixed in Redis 4.0.

Replication storm : Large RDB files, small slave output buffers, and heavy write traffic can cause the master to drop the slave connection repeatedly, leading to endless full‑sync attempts. Solutions include reducing dataset size, increasing buffer limits, and tuning replication settings.

Conclusion

The article groups Redis pitfalls into three areas—command usage, data persistence, and master‑slave replication—explains why each issue occurs, and offers actionable recommendations to prevent performance degradation, data loss, or crashes.