¿Cómo funciona Redis Pub/Sub?

Question

Accepted Answer

**Pub/Sub** (Publicar/Suscribirse) es el patrón de mensajería de Redis donde **publicadores** envían mensajes a **canales** y **suscriptores** reciben mensajes de los canales a los que están suscritos — sin que publicadores y suscriptores se conozcan entre sí. Habilita mensajería en tiempo real y comunicación desacoplada entre servicios.

## El 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.
```

Los publicadores `PUBLISH` a un canal; los suscriptores `SUBSCRIBE` a canales y reciben mensajes en tiempo real. Están **desacoplados** — el publicador no sabe quién (si es que alguien) está escuchando.

## 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)
```

## Limitación 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.
```

## Cuando necesitas confiabilidad: usa 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 qué es importante

Entender Redis Pub/Sub es valioso para **mensajería en tiempo real y comunicación desacoplada**, por lo que es conocimiento útil — pero críticamente, entender sus limitaciones es igualmente importante para usarlo apropiadamente.

Pub/Sub habilita **mensajería en tiempo real** donde los publicadores transmiten a canales y los suscriptores reciben instantáneamente, con publicadores y suscriptores **desacoplados** (sin conocerse entre sí) — impulsando casos de uso como notificaciones en tiempo real, chat, actualizaciones de paneles en vivo, y comunicación de servicios desacoplados (a menudo combinado con WebSockets para enviar actualizaciones a navegadores).

Esto hace que Redis sea una opción simple y rápida para características de transmisión en tiempo real.

Sin embargo, el **punto más importante** es entender la limitación **fire-and-forget** de Pub/Sub: es entrega como máximo una vez — los mensajes llegan solo a los suscriptores conectados en ese momento, y los suscriptores desconectados **pierden permanentemente los mensajes** (sin persistencia, reproducción, confirmación o garantía de entrega).

Esta es una restricción crucial: Pub/Sub no es adecuado cuando importa la entrega confiable o el historial de mensajes, y no entender esto conlleva errores de pérdida de mensajes.

Conocer las alternativas — **Redis Streams** (duradero, basado en log, con grupos de consumidores y confirmaciones) o brokers dedicados (Kafka, RabbitMQ) para mensajería confiable — y elegir Pub/Sub solo para transmisión en tiempo real simple donde es aceptable perder mensajes refleja buen juicio.

Ya que la mensajería en tiempo real es una necesidad común, y ya que Redis Pub/Sub proporciona una solución simple para ella pero con limitaciones importantes de confiabilidad (requiriendo Streams o un broker cuando se necesitan garantías), entender Pub/Sub — cómo funciona, sus casos de uso, y especialmente su limitación fire-and-forget y cuándo usar Streams en su lugar — es conocimiento valioso y prácticamente relevante para implementar características en tiempo real correctamente, donde entender la limitación es tan importante como entender la capacidad.