Is Redis a Viable Message Queue? Comparing List, Pub/Sub, and Stream

1. List as a Simple Queue

Use LPUSH to enqueue and RPOP to dequeue. Both operations are O(1). When the list is empty, RPOP returns NULL. A naive busy‑loop consumer wastes CPU; a common fix is to use the blocking commands BLPOP / BRPOP (e.g., BRPOP queue 0) which block indefinitely until a new element arrives.

2. Pub/Sub

Publish/subscribe uses PUBLISH and SUBSCRIBE. Messages are pushed to all subscribed clients instantly. The model does not persist messages, does not support acknowledgments, and discards messages if no consumer is connected or if Redis restarts. Consumer output buffers are limited (default client-output-buffer-limit pubsub 32mb 8mb 60); exceeding the limit disconnects the client.

3. Streams (Redis 5.0+)

Streams provide a log‑structured data type with the following core commands: XADD – add a new entry; * generates a unique ID of the form timestamp-seq. XREAD – read entries; supports COUNT and BLOCK (e.g., XREAD COUNT 5 BLOCK 0 STREAMS mystream 0-0) for blocking reads. XGROUP – create a consumer group (e.g., XGROUP CREATE mystream group1 0-0). XREADGROUP – read entries as part of a group, enabling multiple consumers to share the same message set. XACK – acknowledge successful processing; unacknowledged entries remain pending and can be re‑delivered. XADD MAXLEN 10000 … – limit stream length to prevent unbounded memory growth.

Streams are persisted to RDB/AOF like other Redis data types, so they survive restarts. Consumer groups allow parallel consumption, reliable replay, and fault‑tolerant processing.

4. Comparison with Dedicated Message Queues

Professional brokers (RabbitMQ, Kafka) guarantee durability via replication and disk storage, provide built‑in flow control, and handle very high throughput. Redis stores data primarily in memory; durability depends on RDB/AOF settings and asynchronous replication, which can still lose data under failure. Memory limits can cause OOM when queues grow large.

5. When to Use Redis as a Queue

Suitable : low‑latency, modest‑volume workloads where occasional data loss is acceptable; simple producer‑consumer patterns; environments that already use Redis for caching.

Not suitable : mission‑critical systems requiring strong durability, high throughput, or large backlogs; scenarios where message loss or memory exhaustion cannot be tolerated.