RabbitMQ vs Redis Pub/Sub

RabbitMQ is a full-featured message broker. Redis Pub/Sub is a lightweight messaging primitive built into Redis. They serve very different reliability requirements.

The Critical Difference: Persistence

RabbitMQ stores messages in queues. If a consumer is temporarily down, messages accumulate and are delivered when the consumer reconnects. With durable queues and persistent messages, data survives broker restarts.

Redis Pub/Sub has zero persistence. When you PUBLISH a message, it is delivered to all currently connected subscribers and then forgotten. If no subscriber is connected, the message is lost. If a subscriber is slow, it misses messages. There is no replay, no queue, and no acknowledgment.

When Redis Pub/Sub Shines

Despite its limitations, Redis Pub/Sub is perfect for:

• Cache invalidation: Broadcast "invalidate key X" to all app instances. If one instance misses it, the cache simply serves stale data slightly longer.
• Real-time notifications: Push updates to connected users. If they are offline, they will fetch current state when they reconnect.
• Live dashboards: Stream metrics to display. Missing a data point is acceptable.

In all these cases, losing a message has minimal impact.

When RabbitMQ Is Necessary

Anytime message loss is unacceptable — task processing, order handling, payment flows — you need RabbitMQ (or a similar broker). Its acknowledgment protocol ensures every message is processed exactly once even through consumer failures.

Redis Streams as a Middle Ground

Redis Streams (XADD/XREAD) offers persistence and consumer groups within Redis, filling the gap between Pub/Sub and RabbitMQ. Consider Streams if you need some reliability without adding a separate broker. See our system design interview guide and caching concepts for more.