Como funciona o Pub/Sub do Redis?

Question

Accepted Answer

**Pub/Sub** (Publish/Subscribe) é o padrão de mensageria do Redis onde **publishers** enviam mensagens para **canais** e **subscribers** recebem mensagens dos canais aos quais estão subscritos — sem que publishers e subscribers se conheçam mutuamente. Isso permite mensageria em tempo real e comunicação desacoplada entre serviços.

## O modelo Pub/Sub

```bash
# Subscriber listens on a channel
SUBSCRIBE news                    # subscribe to the "news" channel

# Publisher sends a message to the channel (in another connection)
PUBLISH news "Breaking story!"    # all subscribers to "news" receive this instantly

# Pattern subscriptions (wildcards)
PSUBSCRIBE news.*                 # subscribe to news.sports, news.tech, etc.
```

Publishers usam `PUBLISH` em um canal; subscribers usam `SUBSCRIBE` em canais e recebem mensagens em tempo real. Eles são **desacoplados** — o publisher não sabe quem (se alguém) está escutando.

## Casos de uso

```text
✓ REAL-TIME notifications — push events to interested services/clients instantly
✓ Chat / messaging — broadcast messages to subscribers
✓ Live updates — dashboards, feeds, multiplayer (broadcast state changes)
✓ Decoupling services — services communicate via channels without direct coupling
✓ Often paired with WebSockets (Redis pub/sub → server → WebSocket → browser)
```

## Limitação importante: fire-and-forget

```text
⚠️ Redis Pub/Sub is FIRE-AND-FORGET (at-most-once delivery):
  → Messages are delivered ONLY to subscribers connected AT THAT MOMENT.
  → If a subscriber is offline/disconnected, it MISSES the message (no storage/replay).
  → No persistence, no acknowledgment, no delivery guarantee.
→ NOT suitable when you need reliable delivery or message history.
```

## Quando você precisa de confiabilidade: use Streams

```text
For RELIABLE messaging (persistence, replay, consumer groups, acknowledgments):
  → use Redis STREAMS (a durable, log-based structure) instead of Pub/Sub
  → or a dedicated message broker (Kafka, RabbitMQ)
Pub/Sub → simple real-time broadcast where missing messages is acceptable
Streams → when you need durability and delivery guarantees
```

## Por que isso importa

Compreender o Pub/Sub do Redis é valioso para **mensageria em tempo real e comunicação desacoplada**, então é um conhecimento útil — mas criticamente, entender suas limitações é igualmente importante para usá-lo apropriadamente.

Pub/Sub permite **mensageria em tempo real** onde publishers fazem broadcast para canais e subscribers recebem instantaneamente, com publishers e subscribers **desacoplados** (desconhecidos um do outro) — capacitando casos de uso como notificações em tempo real, chat, atualizações de dashboards ao vivo e comunicação entre serviços desacoplada (frequentemente combinada com WebSockets para enviar atualizações para navegadores).

Isso torna o Redis uma opção simples e rápida para recursos de broadcast em tempo real.

Entretanto, o **ponto mais importante** é compreender a **limitação fire-and-forget do Pub/Sub**: é entrega no máximo uma vez — mensagens chegam apenas a subscribers conectados naquele momento, e subscribers offline **perdem mensagens permanentemente** (sem persistência, replay, acknowledgment ou garantia de entrega).

Esta é uma restrição crucial: Pub/Sub é inadequado quando entrega confiável ou histórico de mensagens importam, e não entender isso leva a bugs de mensagens perdidas.

Conhecer as alternativas — **Redis Streams** (durável, baseado em log, com grupos de consumers e acknowledgments) ou brokers dedicados (Kafka, RabbitMQ) para mensageria confiável — e escolher Pub/Sub apenas para broadcast em tempo real simples onde perder mensagens é aceitável reflete bom julgamento.

Com a mensageria em tempo real sendo uma necessidade comum, e como o Pub/Sub do Redis oferece uma solução simples para isso mas com importantes limitações de confiabilidade (exigindo Streams ou um broker quando garantias são necessárias), compreender Pub/Sub — como funciona, seus casos de uso, e especialmente sua limitação fire-and-forget e quando usar Streams em vez — é conhecimento valioso e praticamente relevante para implementar recursos em tempo real corretamente, onde entender a limitação é tão importante quanto entender a capacidade.