7 Common Redis Misuse Scenarios and How to Fix Them

01 Proper Use of Collection Types

Case: An activity requires sending reminders to users who participated the previous day. Developers stored daily participants in a sorted set and used ZRANGEBYSCORE and ZREMRANGEBYSCORE to query and delete them. When the participant count reached 50,000, the commands triggered slow‑log alerts because their time complexity is O(log(N)+M).

Analysis: Reduce the query range by splitting a day into smaller intervals (e.g., four‑hour windows) to limit the number of elements processed per command.

Further suggestions: If activity times are highly concentrated, use ZSCAN for iteration, or combine ZRANK, ZRANGE and ZREMRANGEBYRANK to control the number of elements per operation.

02 Proper Expiration Settings

Case 1: A voting feature stored daily vote counts with keys like vote_count_{date} but never set expiration. After a year, more than 360 keys existed, although only two were actively used.

Analysis: Keys that become irrelevant after a short period should have an appropriate TTL so they are automatically removed.

Case 2: A statistics feature imported data batches into a sorted set and scheduled calculations at 30 minutes, 1 day, 3 days, and 7 days. Without cleanup, expired data accumulated in Redis.

Analysis: Since individual elements in a collection cannot have separate TTLs, clean up the batch after the final calculation, e.g., by deleting the entire key.

03 Proper Use of Batch Commands

Scenario: Generating short links requires mapping 50,000 short codes to phone numbers.

Solution 1 (failed): Use HSET in a loop for each entry – caused high ops and timeouts.

Solution 2 (failed): Use HMSET to set all 50,000 entries at once – still triggered slow‑log.

Solution 3 (successful): Use HMSET in batches of 500 entries, repeated 100 times. This reduced the number of commands per request and avoided slow‑log warnings.

Recommendation: For large, frequent HSET workloads, batch writes with HMSET (or MSET for strings) but keep each batch size reasonable (≤ 500 entries).

04 Reduce Unnecessary Requests

Case: A page triggers multiple interface calls that each check a user’s status stored in Redis with an expiration. Keys that are still valid but have a TTL longer than a threshold are refreshed; otherwise they are deleted. Some keys have already expired, leading to redundant DEL commands that waste resources.

Analysis: Use TTL – it returns –2 for non‑existent keys, allowing the application to skip unnecessary DEL operations.

05 Avoid Oversized Values

Case: A product list was serialized into a string and stored in Redis, exceeding 1 MB. The large payload caused packet fragmentation and reduced throughput.

Analysis: Keep string values under 10 KB (1 KB is a practical performance breakpoint). For larger collections, store each item as a field in a hash and retrieve with HSCAN as needed.

Illustration:

06 Design Proper Key Names

Readability: Use a business‑prefix and colon separators, e.g., ACTIVITY:INVITE_REDPACKET:001.

Simplicity: Keep keys short while preserving semantics; long keys increase memory usage.

No Escape Characters: Avoid spaces, line breaks, quotes, or other escape characters in keys.

07 Beware of Disabled Commands

Commands such as KEYS, MONITOR, FLUSHALL, and FLUSHDB should be disabled via Redis’s RENAME mechanism. FLUSHALL / FLUSHDB clear all data; KEYS can cause slow‑log spikes; MONITOR can halve throughput when many clients enable it.

When needed for troubleshooting, these commands can be temporarily enabled on a replica and used with helper tools like redis‑faina.

Conclusion

The guidelines above cover common Redis client‑side pitfalls. By paying attention to collection usage, expiration policies, value sizes, batch operations, request minimization, key naming, and command safety, developers can write healthier Redis code and maintain optimal performance.