Redis Beyond Caching: Distributed Locks, Rate Limiting, Message Queues and More

This is a common Redis interview question that tests a candidate's understanding of Redis use cases, and even if you are not preparing for an interview, the information is valuable for real‑world development.

Redis besides caching – what else can it do?

Distributed lock : Implemented commonly with Redisson.

Rate limiting : Usually achieved with Redis + Lua scripts.

Message queue : Simple queues can be built with List, while Redis 5.0 introduced the Stream data structure for more advanced queuing.

Delayed queue : Provided by Redisson based on Sorted Set.

Distributed session : Store session data in String or Hash, accessible by all servers.

Complex business scenarios : Use structures like Bitmap for active‑user statistics or Sorted Set for leaderboards.

…

How to implement a distributed lock with Redis?

For a detailed guide, see the linked article “How to implement a distributed lock with Redis?”.

Can Redis be used as a message queue?

In practice, few people use Redis as a message queue; you should at least be aware of the concept.

Conclusion: It is possible, but Redis is not recommended as a full‑featured message queue because it lacks many capabilities of dedicated MQ systems.

Before Redis 2.0, a simple queue could be built with List using RPUSH/LPOP or LPUSH/RPOP :

# Producer pushes messages
RPUSH myList msg1 msg2   (integer) 2
RPUSH myList msg3       (integer) 3
# Consumer pops messages
LPOP myList
"msg1"

This polling approach has performance problems because the consumer must constantly call RPOP or LPOP , resulting in many empty requests when the list is empty.

Redis therefore provides blocking commands BLPOP and BRPOP with an optional timeout. If the list is empty, the server waits until new data arrives or the timeout expires (0 means wait indefinitely):

# Timeout of 10 seconds
# Returns immediately if data exists, otherwise waits up to 10 s
BRPOP myList 10
null

However, List‑based queues still lack features such as message acknowledgments and broadcasting; each message can be consumed only once.

Redis 2.0 introduced Pub/Sub, which adds a broadcast mechanism via channels. Publishers use PUBLISH and subscribers use SUBSCRIBE . While Pub/Sub supports both unicast and broadcast and simple pattern matching, it still suffers from message loss (e.g., client disconnects) and backlog issues.

Redis 5.0 added the Stream data structure, offering a more complete message‑queue solution with publish/subscribe, consumer groups, and persistence (RDB/AOF). Using Streams is more complex and still has some drawbacks, such as difficulty guaranteeing “at‑least‑once” delivery after a failover.

Overall, compared with professional message‑queue systems, Redis‑based queues have many shortcomings (message loss, backlog, lack of ACK, etc.). It is generally advisable to use mature MQ solutions like RocketMQ or Kafka instead.