Table of Contents

Real-time with Pub/Sub

What is Pub/Sub?

In a normal client-server interaction, the client asks and the server responds. But what if the server needs to push data to clients without being asked? This is the publish/subscribe pattern.

Publishers send messages to a named channel. Subscribers register interest in channels and receive messages as they arrive. The publisher does not need to know who is listening — the system handles delivery.

Publisher ──► PUBLISH "news" "breaking: ..." ──► nyx-kv
                                                    │
                                    ┌───────────────┼───────────────┐
                                    ▼               ▼               ▼
                              Subscriber A    Subscriber B    Subscriber C

This is called fan-out delivery: one message, many receivers.

Subscribing to a channel

nyx-kv implements Pub/Sub using the standard Redis commands. Connect with any Redis client and subscribe:

$ redis-cli -p 6380
127.0.0.1:6380> SUBSCRIBE alerts
Reading messages... (press Ctrl-C to quit)
1) "subscribe"
2) "alerts"
3) (integer) 1

The response confirms the subscription. The client is now in subscriber mode — it blocks and waits for messages. Only three commands are accepted in this mode: SUBSCRIBE, UNSUBSCRIBE, and PING.

Publishing a message

From another terminal, publish a message to the channel:

$ redis-cli -p 6380
127.0.0.1:6380> PUBLISH alerts "disk usage at 90%"
(integer) 1

The return value is the number of subscribers who received the message. The subscriber sees:

1) "message"
2) "alerts"
3) "disk usage at 90%"

Messages are delivered as a RESP array of three elements: the string "message", the channel name, and the payload.

Multiple channels

A single client can subscribe to multiple channels:

127.0.0.1:6380> SUBSCRIBE alerts notifications system

Messages from any of these channels will be delivered to this subscriber.

Unsubscribing

To stop receiving messages from a channel:

127.0.0.1:6380> UNSUBSCRIBE alerts

Example: live notifications

Here is a practical pattern. A web application publishes events when users perform actions:

# Python publisher (using redis-py)
import redis
r = redis.Redis(port=6380)

# When a user signs up:
r.publish("events", "signup:alice@example.com")

# When an order is placed:
r.publish("events", "order:12345:$49.99")

A monitoring service subscribes and processes events in real time:

# Python subscriber
import redis
r = redis.Redis(port=6380)
p = r.pubsub()
p.subscribe("events")

for msg in p.listen():
    if msg["type"] == "message":
        print(f"Event: {msg['data'].decode()}")

Pub/Sub vs message queues

Pub/Sub and message queues both deliver messages, but they work differently:

FeaturePub/SubMessage Queue
DeliveryAll subscribers get every messageEach message goes to one consumer
PersistenceNo — if nobody is listening, messages are lostYes — messages wait until consumed
AcknowledgmentNo — fire and forgetYes — ACK/NACK required
Use caseLive notifications, chat, eventsBackground jobs, task processing

Summary

← Previous: Building web APIs with nyx-serve Next: Message queues with nyx-queue →