Streams and Consumer Groups

What you'll walk away with

Explain the core ideas behind Streams and Consumer Groups
Run the sample Redis command or code and verify its output
Apply the technique correctly to the Tutorial Platform and production scenarios

Build the mental model

A Redis Stream is an append-only log with ordered entry IDs. Consumer groups distribute entries among consumers and keep delivered-but-unacknowledged entries in a pending list. XACK, XPENDING, and XAUTOCLAIM support recovery, but handlers still need idempotency.

Connect it to a real scenario

XADD tutorial publication jobs to `stream:tutorial-events`; a notification group reads with XREADGROUP. Acknowledge only after email delivery succeeds. Reclaim idle jobs from crashed consumers with XAUTOCLAIM and bound the stream with approximate MAXLEN trimming.

Streams are replayable logs
Use groups, ACKs, and pending recovery
Consumers must be idempotent

Try the working example

shell

XGROUP CREATE stream:tutorial-events notifications $ MKSTREAM
XADD stream:tutorial-events MAXLEN ~ 100000 * type published tutorialId 42
XREADGROUP GROUP notifications worker-1 COUNT 10 BLOCK 5000 STREAMS stream:tutorial-events >
XPENDING stream:tutorial-events notifications
XACK stream:tutorial-events notifications 1787875200000-0
XAUTOCLAIM stream:tutorial-events notifications worker-2 60000 0-0 COUNT 10

You should see

Group workers can distribute jobs, acknowledge them, and recover stale pending entries.

5-minute try-it

Design an idempotency key and dead-letter policy for an at-least-once email worker.

One important caution

Acknowledging immediately after XREADGROUP loses work if processing crashes; acknowledge after the side effect succeeds.

Redis — Streams — Redis

Easy traps

Acknowledging immediately after XREADGROUP loses work if processing crashes; acknowledge after the side effect succeeds.
Validate sample commands on a local or test instance with recoverable data before applying them to production Redis.

Exercise

Design an idempotency key and dead-letter policy for an at-least-once email worker.

You'll know it worked when: Group workers can distribute jobs, acknowledge them, and recover stale pending entries.