Pub/Sub & Streams: Overview
Two messaging models in Redis
Section titled “Two messaging models in Redis”Redis provides two distinct models for passing messages between clients. They serve different needs and are not interchangeable.
| Pub/Sub | Streams | |
|---|---|---|
| Persistence | None — messages vanish after delivery | Durable append-only log |
| Offline subscribers | Miss all messages sent while disconnected | Can catch up from any position |
| Delivery guarantee | Fire-and-forget | At-least-once with consumer groups |
| Message history | No history | Full history by default |
| Consumer groups | Not supported | Supported (parallel processing) |
| Typical latency | Sub-millisecond | Sub-millisecond |
Pub/Sub routes a message to every connected subscriber of a channel, then discards it. Streams append every message to a log that persists independently of any subscriber.
When to use Pub/Sub
Section titled “When to use Pub/Sub”Pub/Sub is the right choice when:
- Real-time notifications — a user action must be broadcast to dashboards or browser tabs instantly and missing one update is acceptable.
- Live chat — messages flow while both parties are connected; chat history is stored elsewhere.
- Fanout cache invalidation — all app servers must drop a cached value at the same time; a missed message just means a slightly stale cache, which is fine.
- Event broadcasting — metrics, presence signals, or ephemeral state updates where older values are meaningless by the time a subscriber reconnects.
The common thread: the value of the message is tied to the moment it was sent. Once that moment passes, the message has no use.
When to use Streams
Section titled “When to use Streams”Streams are the right choice when:
- Event sourcing — every state change must be recorded and replayable from any point in time.
- Task queues — workers process jobs and must not lose a task if a worker crashes.
- Audit logs — a complete, ordered record of who did what, queryable after the fact.
- Offline subscribers — consumers that go down and come back must be able to read everything they missed.
- Parallel processing — consumer groups let multiple workers share a stream without duplicating messages.
The common thread: the message matters even after it has been delivered. You need the log.
What this module covers
Section titled “What this module covers”| Lesson | Topic |
|---|---|
| Overview (this page) | Pub/Sub vs Streams — choosing the right model |
| Pub/Sub | SUBSCRIBE, PUBLISH, UNSUBSCRIBE — the two-terminal demo |
| Pub/Sub Patterns | PSUBSCRIBE, PUNSUBSCRIBE — glob-pattern channel matching |
| Streams | XADD, XREAD, XRANGE, XLEN — writing and reading a stream |
| Consumer Groups | XGROUP, XREADGROUP, XACK — parallel processing with acknowledgement |
127.0.0.1:6379> PUBLISH chat "hello"(integer) 0The reply (integer) 0 means zero subscribers were connected at the time of the publish. Open a second redis-cli session, run SUBSCRIBE chat, then publish again to see a live delivery.
PUBLISH chat "hello"