Come funziona Redis Pub/Sub?

Question

Accepted Answer

**Pub/Sub** (Publish/Subscribe) è il pattern di messaggistica di Redis dove i **publisher** inviano messaggi su **canali** e i **subscriber** ricevono messaggi dai canali ai quali sono iscritti — senza che publisher e subscriber si conoscano reciprocamente. Abilita la messaggistica in tempo reale e la comunicazione disaccoppiata tra servizi.

## Il modello 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.
```

I publisher eseguono `PUBLISH` su un canale; i subscriber eseguono `SUBSCRIBE` ai canali e ricevono i messaggi in tempo reale. Sono **disaccoppiati** — il publisher non sa chi (se qualcuno) sta ascoltando.

## Casi d'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)
```

## Limitazione 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 hai bisogno di affidabilità: 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
```

## Perché è importante

Comprendere Redis Pub/Sub è prezioso per la **messaggistica in tempo reale e la comunicazione disaccoppiata**, quindi è conoscenza utile — ma criticamente, comprendere le sue limitazioni è altrettanto importante per utilizzarlo correttamente.

Pub/Sub abilita la **messaggistica in tempo reale** dove i publisher trasmettono su canali e i subscriber ricevono istantaneamente, con publisher e subscriber **disaccoppiati** (inconsapevoli l'uno dell'altro) — alimentando casi d'uso come notifiche in tempo reale, chat, aggiornamenti live di dashboard, e comunicazione tra servizi disaccoppiata (spesso abbinata a WebSocket per inviare aggiornamenti ai browser).

Questo rende Redis un'opzione semplice e veloce per funzionalità di broadcast in tempo reale.

Tuttavia, il **punto più importante** è comprendere la limitazione **fire-and-forget** di Pub/Sub: è consegna al massimo una volta — i messaggi raggiungono solo i subscriber connessi in quel momento, e i subscriber offline **perdono permanentemente i messaggi** (nessuna persistenza, replay, acknowledgment, o garanzia di consegna).

Questo è un vincolo cruciale: Pub/Sub è inadatto quando la consegna affidabile o la cronologia dei messaggi è importante, e non comprendere questo porta a bug di messaggi persi.

Conoscere le alternative — **Redis Streams** (durevoli, basati su log, con consumer group e acknowledgment) o broker dedicati (Kafka, RabbitMQ) per la messaggistica affidabile — e scegliere Pub/Sub solo per semplici broadcast in tempo reale dove perdere i messaggi è accettabile riflette un buon giudizio.

Poiché la messaggistica in tempo reale è un'esigenza comune, e poiché Redis Pub/Sub fornisce una soluzione semplice per essa ma con importanti limitazioni di affidabilità (richiedendo Streams o un broker quando le garanzie sono necessarie), comprendere Pub/Sub — come funziona, i suoi casi d'uso, e soprattutto la sua limitazione fire-and-forget e quando usare Streams al suo posto — è conoscenza preziosa e praticamente rilevante per implementare correttamente le funzionalità in tempo reale, dove comprendere la limitazione è importante quanto comprendere la capacità.