Three Messaging Tools in One Server

Pub/Sub, lists and Streams

Redis is best known as a cache, but it also offers three ways to move messages between processes. Pub/Sub broadcasts a message to every client currently subscribed to a channel; nothing is stored, so a subscriber that is offline simply misses it (fire-and-forget, at-most-once). Lists used as queues (LPUSH plus blocking BRPOP or BLMOVE) store messages until one consumer pops each one; they give simple work queues, but no replay and limited tracking of in-progress work. Streams (since Redis 5.0) are an append-only log of entries with unique IDs: messages are stored, consumers can read from any point, consumer groups split work between workers with acknowledgements and a pending entries list for recovery, and old entries are trimmed by length or ID. Because all three live in an in-memory server that many teams already run, Redis is an attractive lightweight message bus, as long as you understand its durability and memory limits.

Broadcast, queue and log

Pub/Sub broadcasts and forgets; a list hands each item to one consumer; a stream keeps an ordered log that groups read from.

The same idea in three primitives

Each line shows the core commands of one approach.

# Pub/Sub: live broadcast, nothing stored
SUBSCRIBE notifications              # client A waits
PUBLISH notifications "order shipped" # client B sends; returns number of receivers

# List as a queue: stored until one worker pops it
LPUSH jobs '{"type":"resize","id":42}'
BRPOP jobs 5                          # worker blocks up to 5 s for a job

# Stream: stored log with IDs, readable many times
XADD orders '*' orderId o-1001 status placed
XRANGE orders - +                     # read everything from start to end

Pick the primitive by delivery needs

If losing messages while a subscriber is offline is acceptable, Pub/Sub is the simplest. If every message must be processed, use Streams (or a list-based reliable queue), never plain Pub/Sub.

त्वरित जाँच: A subscriber is disconnected for 10 seconds while messages are published to its Pub/Sub channel. What happens to those messages for that subscriber?

• They are lost for that subscriber
• They are queued until it reconnects
• They move to a stream automatically
• They are delivered twice later