Beyond Caching: Common Redis Use Cases and Their Pitfalls

1. Distributed Lock

Redis can implement a simple distributed lock using SETNX to acquire a lock and DEL to release it, but if the process crashes before releasing, a deadlock occurs.

> setnx lock.test true
OK
... do something ...
> del lock.test
(integer) 1

Adding an expiration time solves the deadlock risk:

> setnx lock.test true
OK
> expire lock.test 5
... do something ...
> del lock.test
(integer) 1

However, a race condition may arise if the server fails between SETNX and EXPIRE . Redis 2.8 introduced an atomic command that combines both actions:

> set lock.test true ex 5 nx
OK
... do something ...
> del lock.test

Locks also suffer from timeout issues; a safer pattern stores a random value with the lock and checks it before deletion, often using a Lua script to guarantee atomicity.

2. Message Queue

2.1 Basic usage : Using Redis lists, LPUSH and RPOP can simulate a FIFO queue.

2.2 Delay queue : A sorted set (ZSET) can act as a delayed queue by storing the execution timestamp as the score and polling for due items.

2.3 Pub/Sub limitations : Pub/Sub provides a publish/subscribe model but drops messages when no consumer is present, loses messages on consumer reconnection, and does not persist data on server failure.

2.4 Stream : Redis 5.0 adds the Stream data type, a durable, multi‑consumer queue inspired by Kafka, though it lacks partitioning.

3. Bitmap

Bitmaps store binary data efficiently; each bit represents a boolean value (e.g., daily sign‑in). Commands SETBIT and GETBIT manipulate individual bits, while BITCOUNT and BITPOS provide counting and position queries.

4. Bloom Filter

Redis modules (available since 4.0) implement Bloom filters with commands BF.ADD , BF.EXISTS , BF.MADD , and BF.MEXISTS . They offer fast membership tests with false positives on existence checks but 100 % accuracy on non‑existence, useful for URL deduplication, spam filtering, and NoSQL query reduction.

5. Geo (Nearby Store/Person/Vehicle)

Redis 3.2 introduced the GEO module, storing latitude/longitude in a sorted set. Queries use the underlying ZSET score ordering to find nearby items, but the internal one‑dimensional mapping (GeoHash) introduces slight precision loss, and large GEO datasets are recommended to run on a dedicated Redis instance.

6. Rate Limiting

6.1 Simple rate limiting : A ZSET stores timestamps as scores; counting entries within a time window yields the request count. This approach can be memory‑intensive for high‑traffic keys.

6.2 Leaky‑bucket rate limiting : The Redis‑Cell module (Redis 4.0) provides an atomic CL.THROTTLE command implementing the leaky‑bucket algorithm.

7. Summary

The article emphasizes that Redis’s rich data structures enable many scenarios beyond caching, such as distributed coordination, queuing, bit‑level analytics, probabilistic data structures, geospatial queries, and traffic shaping. Understanding these patterns helps developers leverage Redis more effectively and avoid common pitfalls.