Real-time notification pattern in Redis - Step-by-Step Execution

Concept Flow - Real-time notification pattern

Client A publishes message

↓

Redis receives message

↓

Redis broadcasts message to subscribers

↓

Client B receives notification

↓

Client B processes notification

This flow shows how a message published by one client is received by Redis and then broadcast to all subscribed clients in real-time.

Execution Sample

Redis

PUBLISH notifications "New message"
SUBSCRIBE notifications

Client A publishes a message to the 'notifications' channel; Client B subscribes and receives it immediately.

Execution Table

Step	Action	Redis State	Clients State	Output/Result
1	Client B subscribes to 'notifications'	Channel 'notifications' has 1 subscriber (Client B)	Client B waiting for messages	No output yet
2	Client A publishes 'New message' to 'notifications'	Message published to 'notifications' channel	Client B receives 'New message'	Client B outputs notification: 'New message'
3	Client B processes the notification	No change	Client B processed message	Notification handled
4	No more messages	No new messages in channel	Clients idle	Waiting for next publish

💡 No more messages published; clients remain subscribed waiting for new notifications

Variable Tracker

Variable	Start	After Step 1	After Step 2	After Step 3	Final
Redis Channel 'notifications' Subscribers	0	1 (Client B)	1 (Client B)	1 (Client B)	1 (Client B)
Published Message for 'notifications'	empty	empty	"New message"	empty	empty
Client B State	disconnected	subscribed, waiting	received message	processed message	waiting

Key Moments - 2 Insights

Why does Client B receive the message immediately after Client A publishes it?

Because Client B is subscribed to the 'notifications' channel before the message is published, as shown in execution_table step 1 and 2.

What happens if Client B subscribes after Client A publishes the message?

Client B will not receive the past message because Redis Pub/Sub only delivers messages to clients subscribed at the time of publishing, as implied by the execution_table.

Visual Quiz - 3 Questions

Look at the execution_table at step 2, what is the Redis state?

A Message published to 'notifications' channel

B Channel 'notifications' has 0 subscribers

C No messages in queue

D Client B disconnected

💡 Hint

Check the 'Redis State' column at step 2 in execution_table

At which step does Client B process the notification?

A Step 1

B Step 2

C Step 3

D Step 4

💡 Hint

Look at the 'Clients State' and 'Output/Result' columns in execution_table

If Client B subscribes after Client A publishes, what changes in the execution_table?

A Client B receives the message immediately

B Client B does not receive the past message

C Message queue holds the message until Client B subscribes

D Redis stores the message permanently

💡 Hint

Refer to key_moments explanation about subscription timing and message delivery

Concept Snapshot

Real-time notification pattern uses Redis Pub/Sub.
Clients subscribe to channels to receive messages.
Publishers send messages to channels.
Redis broadcasts messages instantly to all subscribers.
Subscribers only get messages published after they subscribe.

Full Transcript

The real-time notification pattern in Redis works by clients subscribing to channels. When a client publishes a message to a channel, Redis immediately broadcasts it to all clients subscribed to that channel. The execution flow starts with a client subscribing, then another client publishing a message. Redis broadcasts the message to subscribers. The subscriber receives and processes the message. If a client subscribes after a message is published, it will not receive that past message because Redis Pub/Sub delivers only to current subscribers. This pattern enables instant notifications between clients using Redis channels.