Pub/Sub Messaging

What you'll walk away with

Explain the core ideas behind Pub/Sub Messaging
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

Redis Pub/Sub connects publishers and subscribers through channels. It has no message history, acknowledgement, or replay, so messages are lost while a subscriber is disconnected. It fits presence and disposable live UI hints; use Streams for reliable jobs or audit events.

Connect it to a real scenario

When a tutorial is published, send a small event ID to `tutorial:published`; WebSocket gateways subscribe and fetch durable API data by ID. Keep subscriber connections separate from regular command connections.

Pub/Sub is ephemeral
Disconnected subscribers miss messages
Fetch durable payloads from the DB or API

Try the working example

shell

SUBSCRIBE tutorial:published
PSUBSCRIBE tutorial:*

PUBLISH tutorial:published '{"tutorialId":42,"version":3}'
PUBSUB NUMSUB tutorial:published

You should see

Online subscribers receive the event immediately; offline subscribers cannot replay it.

5-minute try-it

Explain whether presence indicators or payment events belong on Pub/Sub.

One important caution

Do not treat Pub/Sub delivery as job completion; there is no acknowledgement.

Redis — Pub/Sub — Redis

Easy traps

Do not treat Pub/Sub delivery as job completion; there is no acknowledgement.
Validate sample commands on a local or test instance with recoverable data before applying them to production Redis.

Exercise

Explain whether presence indicators or payment events belong on Pub/Sub.

You'll know it worked when: Online subscribers receive the event immediately; offline subscribers cannot replay it.