Redis/Pub/Sub lab

Pub/Sub Lab: Fire-And-Forget vs Streams

This lab compares Redis Pub/Sub with Redis Streams by taking one subscriber offline in the middle of a message run.

Break modePUBLISH sends only to subscribers connected at that moment.

Fix modeXADD stores messages so a consumer can reconnect and catch up.

InvariantIf every message matters, offline consumers must not lose messages.

fan out

offline

stored

catch up

Redis Commands

Opens a live subscription. The client receives future messages while connected.

Sends a payload to currently connected subscribers. Return value is subscriber count, not durable delivery proof.

Creates a stream consumer group for the durable comparison path.

Stores a message in a stream so it can be read later.

Reads stored stream messages for a consumer group.

Acknowledges that a stream message has been processed.

Pattern	Use when	Avoid when
Pub/Sub	Live fan-out where missed messages are acceptable, such as local invalidation signals or ephemeral notifications.	Jobs, payments, orders, audit events, or anything that must be replayed.
Streams	Consumers need backlog, ack, retry, or crash recovery.	You only need a transient signal and do not want to manage retention.

Pub/Sub mode. Look for SUB-B going offline and missing messages permanently.

Streams mode. Look for the consumer catching up after reconnect.

Runs the streams comparison with more messages.

Pub/Sub is fire-and-forget. It does not keep messages for disconnected clients.
A successful PUBLISH does not mean every logical consumer processed the message.
Streams are stronger, but they require trimming, consumer-group monitoring, and idempotent handlers.

Code	Why it matters
`cmd/pubsub/main.go`	The offline subscriber case and the streams comparison path.
`pubsub/Makefile`	Targets for fire-and-forget breakage and stream-backed recovery.
`pubsub/compose.yaml`	Redis container used by the lab.
`pubsub/README.md`	Expected output for message loss and stream catch-up.