Beyond Caching: How Redis Powers Distributed Locks, Queues, and More

Redis Beyond Caching

Distributed lock : Commonly implemented with Redisson, which uses the Redis SET key value NX PX ttl pattern to guarantee mutual exclusion.

Rate limiting : Implemented with Redis counters or Lua scripts that atomically increment a key and set an expiration.

Message queue : Simple FIFO queues can be built with the List type; Redis 5.0 introduced Stream, which provides a richer publish/subscribe model with consumer groups and persistence.

Delay queue : Implemented via a Sorted Set where the score represents the delivery timestamp; Redisson offers a built‑in delay‑queue abstraction.

Distributed session : Session data can be stored in String or Hash structures, making it accessible to all application instances.

Complex business scenarios : Bitmap for active‑user statistics, Sorted Set for leaderboards, etc.

Distributed Lock with Redis

Redisson provides a high‑level API for distributed locks that internally uses the SET key value NX PX ttl command to acquire a lock atomically and a Lua script to release it safely. The lock is re‑entrant and supports automatic lease renewal.

Using Redis as a Message Queue

Below are the basic patterns for building a queue with Redis List structures.

Simple List Queue

# Producer pushes messages
RPUSH myList msg1 msg2
# Consumer pops messages
LPOP myList   # returns "msg1"

Polling with LPOP or RPOP wastes CPU when the list is empty. Redis offers blocking variants that wait for data.

# Block for up to 10 seconds for a message
BRPOP myList 10   # returns a message or null after timeout

Limitations of List Queues

No built‑in acknowledgment – if a consumer crashes after popping, the message is lost.

Only a single consumer can receive each element; no broadcast capability.

No native support for dead‑letter handling or retry policies.

Pub/Sub Messaging

Redis 2.0 introduced publish/subscribe. Publishers send messages with PUBLISH channel message; subscribers listen with SUBSCRIBE channel. This model supports one‑to‑many delivery but does not persist messages, so any subscriber that is offline will miss messages.

Redis Streams for Reliable Queues

Redis 5.0 added the Stream data type, which combines a log‑structured storage model with consumer‑group semantics.

Appending messages : XADD mystream * field1 value1 field2 value2 Creating a consumer group : XGROUP CREATE mystream mygroup $ Reading messages (parallel consumption):

XREADGROUP GROUP mygroup consumer1 COUNT 10 BLOCK 2000 STREAMS mystream >

Acknowledging : XACK mystream mygroup 1526981058136-0 Streams provide:

Publish/subscribe semantics.

Consumer groups for load‑balanced parallel processing.

Message persistence via RDB/AOF.

Drawbacks include added complexity and the possibility of message loss after a failover if the stream’s replication state is not fully synchronized.

Recommendation

Redis can be used for lightweight queuing, rate limiting, and distributed coordination, but it lacks many reliability features of dedicated messaging systems (e.g., guaranteed delivery, dead‑letter queues, back‑pressure handling). For production‑grade message queuing, consider specialized platforms such as Apache Kafka or RocketMQ.