When to use Pub/Sub vs Streams vs a job queue in Redis

Choosing the right messaging primitive

Redis offers three distinct messaging patterns. Use the wrong one and you will either lose messages or overcomplicate your system.

Use Pub/Sub when

You need real-time broadcast to multiple clients and can accept message loss. Examples: live chat, presence updates, dashboard refresh signals. If a subscriber is offline, they miss the event — that is acceptable.

Use Streams when

You need message persistence, replay, or multiple independent consumers each processing the full log. Examples: event sourcing, audit trails, ETL pipelines. Consumer groups add reliable at-least-once delivery to Streams.

Use a List-based queue (or BullMQ) when

Each message must be processed by exactly one consumer and you want simple FIFO semantics without the overhead of Streams. RPUSH + BLPOP is the simplest queue.

# Producer
RPUSH task:queue '{"type":"email","to":"user@example.com"}'

# Consumer
BLPOP task:queue 0   # blocks until item available

Decision summary

Fan-out to all → Pub/Sub. Durable log with replay → Streams. Single-consumer job queue → List + BLPOP (or BullMQ for retries and priorities).