Redis Pub/Sub or RabbitMQ? When to Pick Which

Picking a messaging layer is usually a multi-year decision. If you realize it was wrong, migrating is painful. That's why it's worth asking the right questions up front.

In our platform both Redis Pub/Sub and RabbitMQ are in active use. Both are necessary. This post walks through how we made the call, and when I reach for which.

First: they solve different problems

Redis Pub/Sub and RabbitMQ show up in the same sentence a lot, but they're fundamentally different tools.

Redis Pub/Sub — fire-and-forget broadcast. You publish; anyone listening at that instant gets the message. Anyone not listening misses it. No persistence, no ack, no retry.

RabbitMQ — a durable (or semi-durable) queue. You enqueue; consumers pull in order, process, ack. Unprocessed messages aren't lost (for durable queues).

These two models are not alternatives for the same problem — they're designed for different problems.

When Redis Pub/Sub is right

Ideal scenarios:

• A game server broadcasting state updates to all players in a room
• A live leaderboard pushing score changes to every connected client
• A chat room fanning a message out to everyone in it
• A config change signaling all services to reload

Common thread: fast, wide, loss-tolerable. A position update lost in a game will be caught by the next one arriving. What matters is speed of fanout, not durability.

Latency: sub-millisecond. No other broker easily matches that.

When RabbitMQ is right

Ideal scenarios:

• Sending a payment notification for an order
• Tournament results being computed and rewards dispatched
• Welcome email after user signup
• Analytics events going to the data warehouse

Common thread: loss is unacceptable, but milliseconds don't matter. A payment notification can be 500ms late, but must never be lost. A welcome email can arrive 2 seconds later, not never.

RabbitMQ fits because it gives you persistence, ack/nack, DLQ, retry, and routing — the backbone of business-critical flows.

Four questions for the decision

For every new workflow I ask myself these:

1. Would losing this message actually break the business? Yes → RabbitMQ No → Redis Pub/Sub

2. Is speed of fanout more important than completeness? Speed → Redis Completeness → RabbitMQ

3. What should happen if a consumer is offline? "Resume when it comes back" → RabbitMQ "Missed updates are fine to forget" → Redis

4. How many consumers? 1–3 → RabbitMQ is usually clearer 100–1000 → Redis Pub/Sub scales more easily

A real case where we picked wrong — and paid for it

Years back, we chose Redis Pub/Sub for player notifications. The reasoning was thin: "Redis is already there, no new infra, fast delivery is good."

Three months later we noticed: notifications sent to offline players were just gone. When they came back they never received "you won ₺X." Customer support tickets piled up.

The migration took six weeks. New RabbitMQ queue, new consumers, a bridge between the old and new notification systems. Work nobody wanted.

The lesson: don't use Redis Pub/Sub for anything that requires persistence. One minute of thinking up front saves you six weeks later.

What does running both look like

Current split:

• Redis Pub/Sub — in-room game state, lobby updates, live scores, real-time metric fanout
• RabbitMQ — payments events, tournament results, notifications, email, outbound events to partner systems

Each team uses the right tool for the right job. Nobody is confused because the "why Rabbit, why Redis" rule was published with the team on day one.

What about Kafka?

Natural question: why no Kafka? Kafka is great, but most of our workloads sit outside Kafka's strength. We don't have millions-of-events-per-second throughput. No event sourcing. Replay is rarely needed.

Introducing and running Kafka would be a disproportionate investment. RabbitMQ covers what we need on the durable side, Redis covers the broadcast side, so we didn't add something we wouldn't fully use.

Takeaway

There's no single right answer for choosing a messaging layer. But there are wrong ones — and the way to avoid them is to ask those four questions for every workflow. "We already had it, so we used it" is a phrase that tends to end in regret six months later.

Learn both tools. Know where each fits. Then picking becomes easy.