Kako funkcionira Redis Pub/Sub?

Question

Accepted Answer

**Pub/Sub** (Publish/Subscribe) je Redis-ov messaging pattern gdje **publisheri** šalju poruke na **kanale** a **subscriberi** primaju poruke s kanala na koje su pretplaćeni — bez da publisheri i subscriberi znaju jedni o drugima. Omogućava real-time messaging i decoupled komunikaciju između servisa.

## Pub/Sub model

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

Publisheri koriste `PUBLISH` na kanalu; subscriberi koriste `SUBSCRIBE` na kanale i primaju poruke u real-time. Oni su **decoupled** — publisher ne zna tko (ako netko) sluša.

## Primjene

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

## Važno ograničenje: 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.
```

## Kada vam treba pouzdanost: koristite 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
```

## Zašto je to važno

Razumijevanje Redis Pub/Sub-a je vrijedna stavka jer podržava **real-time messaging i decoupled komunikaciju**, pa je to korisno znanje — ali kritično je jednako važno razumjeti njegova ograničenja kako bi se koristilo na pravi način.

Pub/Sub omogućava **real-time messaging** gdje publisheri emitiraju na kanale a subscriberi primaju instant, s publisherima i subscriberima koji su **decoupled** (nesvjesni jedni drugih) — što omogućava primjene kao što su real-time notifikacije, chat, live dashboard ažuriranja, i decoupled komunikacija između servisa (često u kombinaciji s WebSocketima za slanje ažuriranja do preglednika).

To čini Redis jednostavnom, bržom opcijom za real-time broadcast funkcionalnosti.

Međutim, **najvažnija stavka** je razumijevanje Pub/Sub-ovog **fire-and-forget ograničenja**: to je at-most-once dostava — poruke dosežu samo subscribere koji su spojeni u tom trenutku, a offline subscriberi **trajno gube poruke** (bez perzistencije, mogućnosti ponovnog čitanja, acknowledgmenta, ili garancije dostave).

Ovo je kritično ograničenje: Pub/Sub nije prikladan kada pouzdana dostava ili povijest poruka imaju značenja, a nerazumijevanje ovoga vodi do bugova s izgubljenim porurama.

Znanja o alternativama — **Redis Streams** (duralni, log-bazirani, s consumer groupama i acknowledgmentima) ili dedicirani brokeri (Kafka, RabbitMQ) za pouzdani messaging — i odabir Pub/Sub-a samo za jednostavni real-time broadcast gdje je prihvatljivo izgubiti poruke odražava dobar prosudbe.

Budući da je real-time messaging česta potreba, i budući da Redis Pub/Sub pruža jednostavno rješenje za to ali s važnim ograničenjima pouzdanosti (zahtijeva Streams ili brokera kada su garancije potrebne), razumijevanje Pub/Sub-a — kako funkcionira, njegove primjene, i posebno njegove fire-and-forget ograničenja i kada koristiti Streams umjesto toga — je vrijedna, praktično relevantna znanja za ispravnu implementaciju real-time funkcionalnosti, gdje je razumijevanje ograničenja jednako važno kao razumijevanje mogućnosti.