Hvordan fungerer Redis Pub/Sub?

Question

Accepted Answer

**Pub/Sub** (Publish/Subscribe) er Redis's messaging-mønster, hvor **publishere** sender beskeder til **kanaler** og **subscribers** modtager beskeder fra kanaler, de er abonneret på — uden at publishere og subscribers kender til hinanden. Det muliggør real-time messaging og dekoblet kommunikation mellem tjenester.

## Pub/Sub-modellen

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

Publishers `PUBLISH` til en kanal; subscribers `SUBSCRIBE` til kanaler og modtager beskeder i real-time. De er **dekoblede** — publisheren ved ikke, hvem (hvis nogen) der lytter.

## Use cases

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

## Vigtig begrænsning: 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.
```

## Når du skal bruge pålidelighed: brug 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
```

## Hvorfor det betyder noget

At forstå Redis Pub/Sub er værdifuldt for **real-time messaging og dekoblet kommunikation**, så det er nyttig viden — men kritisk set er det lige så vigtig at forstå dets begrænsninger for at bruge det korrekt.

Pub/Sub muliggør **real-time messaging**, hvor publishere sender til kanaler og subscribers modtager øjeblikkeligt, med publishere og subscribers **dekoblede** (uvidende om hinanden) — hvilket driver use cases som real-time notifikationer, chat, live dashboard-opdateringer og dekoblet servicekommunikation (ofte kombineret med WebSockets for at skubbe opdateringer til browsere).

Dette gør Redis til et simpelt, hurtigt valg til real-time broadcast-funktioner.

Men det **vigtigste punkt** er at forstå Pub/Sub's **fire-and-forget-begrænsning**: det er at-most-once delivery — beskeder når kun subscribers, der er forbundet på det tidspunkt, og offline subscribers **mister permant beskeder** (ingen persistering, replay, bekræftelse eller leveringsgaranti).

Dette er en afgørende begrænsning: Pub/Sub er uegnet, når pålidelig levering eller beskedhistorik betyder noget, og hvis man ikke forstår dette, fører det til lost-message bugs.

At kende alternativerne — **Redis Streams** (holdbar, log-baseret, med consumer groups og bekræftelser) eller dedikerede brokers (Kafka, RabbitMQ) for pålidelig messaging — og vælge Pub/Sub kun til simpel real-time broadcast, hvor det er acceptabelt at misse beskeder, afspejler godt skøn.

Fordi real-time messaging er et almindeligt behov, og fordi Redis Pub/Sub giver en simpel løsning til det, men med vigtige pålideligheds-begrænsninger (som kræver Streams eller en broker, når garantier er nødvendige), er forståelse af Pub/Sub — hvordan det fungerer, dets use cases og især dets fire-and-forget-begrænsning og hvornår man skal bruge Streams i stedet — værdifuld, praktisk-relevant viden for at implementere real-time-funktioner korrekt, hvor forståelse af begrænsningen er lige så vigtig som forståelse af muligheden.