Wat zijn Redis Streams?

Question

Accepted Answer

**Redis Streams** zijn een append-only log data structure — zoals een duurzame message queue of event log — die **consumer groups**, message persistence, acknowledgments en replay ondersteunen. Ze zijn Redis's antwoord op betrouwbaar messaging, robuuster dan Pub/Sub (wat fire-and-forget is).

## Append-only log van berichten

```bash
# add entries to a stream (each gets an auto ID: timestamp-sequence)
XADD events * type "signup" user "ann"     # * = auto-generate ID; returns e.g. 1700000000-0
XADD events * type "login" user "bob"

XLEN events                                 # number of entries
XRANGE events - +                           # read all entries (- to +)
XREAD COUNT 10 STREAMS events 0             # read entries (from ID 0)
```

Streams zijn een **append-only log**: entries worden toegevoegd met `XADD` (elk met een unieke, tijd-geordende ID) en blijven in de stream — anders dan Pub/Sub, berichten gaan niet verloren; ze worden opgeslagen en kunnen opnieuw gelezen worden.

## Consumer groups — betrouwbare, schaalbare verwerking

```bash
# create a consumer group to process the stream
XGROUP CREATE events workers 0

# consumers read messages (each message goes to ONE consumer in the group)
XREADGROUP GROUP workers consumer1 COUNT 1 STREAMS events >

# acknowledge a processed message (so it's not redelivered)
XACK events workers 1700000000-0
# unacknowledged messages can be reclaimed (XPENDING/XCLAIM) → no message lost on crash
```

**Consumer groups** verdelen berichten over meerdere consumers (schaalbaarheid van verwerking), waarbij elk bericht naar één consumer gaat, **acknowledgments** (`XACK`) bevestigen verwerking, en **pending/reclaim** (`XPENDING`/`XCLAIM`) zorgen ervoor dat berichten niet verloren gaan als een consumer crasht — betrouwbare, at-least-once delivery.

## Streams vs Pub/Sub

```text
PUB/SUB  → fire-and-forget; offline subscribers MISS messages; no persistence/replay
STREAMS  → PERSISTENT log; messages stored; consumer groups; acknowledgments; replay
  → Streams = when you need RELIABLE delivery, message history, and scalable consumers
  → Pub/Sub = simple real-time broadcast where missing messages is OK
Streams are similar to a lightweight Kafka (log + consumer groups).
```

## Waarom het belangrijk is

Begrepen van Redis Streams is waardevol voor **betrouwbare messaging en event processing** binnen Redis, dus het is nuttige kennis — vooral omdat Streams de belangrijkste beperkingen van Pub/Sub aanpakken.

Terwijl Pub/Sub eenvoudig maar fire-and-forget is (offline abonnees missen berichten permanent, geen persistence), **bieden Streams betrouwbaar messaging**: een **append-only persistent log** waar berichten worden opgeslagen (niet verloren) en opnieuw kunnen worden gelezen/hergespeeld, plus **consumer groups** die berichten over meerdere consumers verdelen voor schaalbare verwerking, **acknowledgments** (`XACK`) om verwerking te bevestigen, en **pending-message reclaim** (`XPENDING`/`XCLAIM`) zodat berichten niet verloren gaan als een consumer crasht — at-least-once, betrouwbare, schaalbare message processing.

Begrepen van **Streams vs Pub/Sub** (Streams voor betrouwbare delivery, history en schaalbare consumers; Pub/Sub voor eenvoudige real-time broadcast waar verlies acceptabel is) is belangrijk voor het kiezen van de juiste Redis messaging primitive.

Herkennen dat Streams **vergelijkbaar zijn met een lichtgewicht Kafka** (log-based met consumer groups) helpt hun rol in te kaderen — event-streaming/message-queue mogelijkheden binnen Redis bieden zonder een aparte broker voor matige behoeften, terwijl dedicated brokers (Kafka, RabbitMQ) geschikt blijven voor grotere of meer veeleisende messaging.

Aangezien betrouwbare messaging en event processing gemeenschappelijke behoeften zijn, en aangezien Redis Streams een robuuste, persistent, consumer-group-based oplossing bieden (Pub/Sub's fire-and-forget beperking overwinnen) binnen Redis, is het begrijpen van Redis Streams — de append-only log, consumer groups met acknowledgments en reclaim, en hoe ze zich verhouden tot Pub/Sub en Kafka — waardevolle, praktisch relevante kennis voor het bouwen van betrouwbare messaging en event-driven features met Redis, de juiste keuze wanneer u delivery guarantees en message history nodig hebt die Pub/Sub niet kan bieden.