Hoe werkt Redis Pub/Sub?

Question

Accepted Answer

**Pub/Sub** (Publish/Subscribe) is het berichtpatroon van Redis waarbij **uitgevers** berichten naar **kanalen** sturen en **abonnees** berichten van kanalen waarop ze zijn geabonneerd ontvangen — zonder dat uitgevers en abonnees iets van elkaar afweten. Het maakt realtime-berichten en ontkoppelde communicatie tussen services mogelijk.

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

Uitgevers gebruiken `PUBLISH` op een kanaal; abonnees gebruiken `SUBSCRIBE` op kanalen en ontvangen berichten in realtime. Ze zijn **ontkoppeld** — de uitgever weet niet wie (zo al iemand) luistert.

## Gebruiksscenario's

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

## Belangrijke beperking: 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.
```

## Als je betrouwbaarheid nodig hebt: gebruik 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
```

## Waarom het belangrijk is

Het begrijpen van Redis Pub/Sub is waardevol voor **realtime-berichten en ontkoppelde communicatie**, dus het is nuttige kennis — maar kritiek is het begrijpen van de beperkingen ervan even belangrijk om het passend in te zetten.

Pub/Sub maakt **realtime-berichten** mogelijk waarbij uitgevers naar kanalen uitzenden en abonnees berichten onmiddellijk ontvangen, met uitgevers en abonnees **ontkoppeld** (onwetend van elkaar) — wat gebruiksscenario's mogelijk maakt zoals realtime-meldingen, chat, live dashboardupdates en ontkoppelde servicecommunicatie (vaak gecombineerd met WebSockets om updates naar browsers te pushen).

Dit maakt Redis een eenvoudige, snelle optie voor realtime-uitzendfeatures.

De **meest belangrijke punt** is echter het begrijpen van de **fire-and-forget-beperking** van Pub/Sub: het is at-most-once levering — berichten bereiken alleen abonnees die op dat moment verbonden zijn, en offline abonnees **missen berichten permanent** (geen persistentie, replay, bevestiging of leveringsgarantie).

Dit is een cruciale beperking: Pub/Sub is ongeschikt wanneer betrouwbare levering of berichtgeschiedenis belangrijk is, en het niet begrijpen ervan leidt tot bugs met verloren berichten.

Het kennen van alternatieven — **Redis Streams** (duurzaam, loggebaseerd, met consumentengroepen en bevestigingen) of specifieke brokers (Kafka, RabbitMQ) voor betrouwbare berichten — en Pub/Sub alleen kiezen voor eenvoudige realtime-uitzending waar gemiste berichten acceptabel zijn, weerspiegelt goed inzicht.

Omdat realtime-berichten een veel voorkomende behoefte zijn, en omdat Redis Pub/Sub een eenvoudige oplossing biedt maar met belangrijke betrouwbaarheidslimieten (waarbij Streams of een broker nodig zijn als garanties vereist zijn), is het begrijpen van Pub/Sub — hoe het werkt, zijn gebruiksscenario's, en vooral zijn fire-and-forget-beperking en wanneer Streams in plaats daarvan gebruikt moet worden — waardevol, praktisch relevant weten voor correct implementeren van realtime-features, waarbij het begrijpen van de beperking even belangrijk is als het begrijpen van de mogelijkheid.