Cum funcționează Redis Pub/Sub?

Question

Accepted Answer

**Pub/Sub** (Publish/Subscribe) este modelul de messaging al Redis în care **publisherii** trimit mesaje la **canale** și **subscriberii** primesc mesaje din canalele la care sunt abonați — fără ca publisherii și subscriberii să se cunoască între ei. Permite messaging în timp real și comunicare decuplată între servicii.

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

Publisherii `PUBLISH` pe un canal; subscriberii `SUBSCRIBE` la canale și primesc mesaje în timp real. Sunt **decuplați** — publisherul nu știe cine (dacă cineva) ascultă.

## Cazuri de utilizare

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

## Limitare importantă: 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.
```

## Când aveți nevoie de fiabilitate: utilizați 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
```

## De ce contează

Înțelegerea Redis Pub/Sub este valoroasă pentru **messaging în timp real și comunicare decuplată**, deci este cunoaștere utilă — dar în mod critic, înțelegerea limitărilor sale este la fel de importantă pentru a-l folosi corespunzător.

Pub/Sub permite **messaging în timp real** în care publisherii transmit la canale și subscriberii primesc instantaneu, cu publisheri și subscriberi **decuplați** (inconștienți unul de altul) — alimentând cazuri de utilizare precum notificări în timp real, chat, actualizări live ale tabloului de bord și comunicare decuplată între servicii (adesea combinată cu WebSockets pentru a trimite actualizări către browsere).

Aceasta face Redis o opțiune simplă și rapidă pentru caracteristici de broadcast în timp real.

Cu toate acestea, **cel mai important punct** este înțelegerea limitării **fire-and-forget** a Pub/Sub: este livrare cel mult o dată — mesajele ajung doar la subscriberii conectați la acel moment, iar subscriberii offline **pierd permanent mesajele** (fără persistență, redare, confirmare sau garanție de livrare).

Acesta este un constraint crucial: Pub/Sub nu este potrivit când livrarea fiabilă sau istoricul mesajelor contează, și neînțelegerea acestui lucru duce la buguri de mesaje pierdute.

Cunoașterea alternativelor — **Redis Streams** (durabil, bazat pe jurnal, cu grupuri de consumatori și confirmări) sau brokeri dedicați (Kafka, RabbitMQ) pentru messaging fiabil — și alegerea Pub/Sub doar pentru broadcast simplu în timp real în care ratarea mesajelor este acceptabilă reflectă o decizie bună.

Întrucat messaging în timp real este o nevoie comună, și întrucât Redis Pub/Sub oferă o soluție simplă pentru aceasta dar cu limitări importante de fiabilitate (necesitând Streams sau un broker atunci când sunt necesare garanții), înțelegerea Pub/Sub — cum funcționează, cazurile sale de utilizare și în special limitarea fire-and-forget și când să utilizați Streams în schimb — este cunoaștere valoroasă și practic relevantă pentru implementarea corectă a caracteristicilor în timp real, unde înțelegerea limitării este la fel de importantă ca înțelegerea capabilității.