# Three Messaging Tools in One Server — Redis Pub/Sub & Streams

Source: https://www.skillbyai.com/en/redis-streams/f-options

> Distinguish Pub/Sub, lists and Streams as messaging primitives in Redis.

## 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.

![Three panels: a speaker icon sending waves to several listeners; a vertical stack with one item leaving the bottom; a long horizontal strip with numbered cells and two reader markers.](assets/figures/redis-streams/section-1-map.svg) — Figure 1.1 — Pub/Sub, lists and Streams compared.

## The same idea in three primitives

Each line shows the core commands of one approach.

```bash
# 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.

**Quiz:** A subscriber is disconnected for 10 seconds while messages are published to its Pub/Sub channel. What happens to those messages for that subscriber?

- [x] They are lost for that subscriber
- [ ] They are queued until it reconnects
- [ ] They move to a stream automatically
- [ ] They are delivered twice later

*Answer:* They are lost for that subscriber. Redis Pub/Sub stores nothing; only currently connected subscribers receive messages.