Queues vs Pub/Sub

In a message queue, each message is consumed by exactly one worker (competing consumers). In pub/sub, a message published to a topic is delivered to all subscribers simultaneously. One event, many consumers — this is fan-out.

Redis Pub/Sub

// Publisher
const publisher = new Redis();
await publisher.publish('user.created', JSON.stringify({ userId: 42 }));

// Subscriber
const subscriber = new Redis();
await subscriber.subscribe('user.created');
subscriber.on('message', (channel, message) => {
  const event = JSON.parse(message);
  // send welcome email, update analytics, etc.
});

Redis Pub/Sub is in-memory and does not persist messages. If a subscriber is offline when a message is published, the message is lost. For durability, use Redis Streams or a dedicated broker such as Kafka or RabbitMQ.

When to Use Pub/Sub

Use pub/sub for real-time notifications, live dashboards, and cross-service event broadcasting. Use a job queue when you need durability, retries, and exactly-one processing semantics. Most event-driven systems use both: pub/sub for real-time fan-out, queues for reliable background processing triggered by those events.