Learning Redis - Pub/Sub Messaging & Keyspace Notifications

#Introduction

So far you've always pulled data from Redis. Episode 8 reverses the direction: you'll learn how Redis pushes data to applications in real time via Pub/Sub, plus the keyspace notifications feature that lets applications hear key changes.

Pub/Sub is the simplest broadcast mechanism in Redis — a publisher sends a message to a channel, and every subscriber listening on it receives it instantly. This is the basic pattern for real-time notifications like chat, WebSocket broadcast, and alerting. Let's begin.

#Publish/Subscribe

#The Fire-and-Forget Model

Pub/Sub works with a simple model: a message is sent to a channel, and all clients currently subscribed to that channel receive it instantly. There is no storage — if there are no subscribers when the message is sent, the message is lost forever.

publisher ──> PUBLISH news "Hello" ──> channel news
                                        ├──> subscriber A
                                        └──> subscriber B

#SUBSCRIBE and PUBLISH

Open two terminals. The first terminal subscribes to a channel:

redis-cli SUBSCRIBE news

redis-cli SUBSCRIBE news connects the terminal to the news channel. Subscribe mode is exclusive: while subscribed, the client cannot run any other commands. On the second terminal, send a message:

redis-cli PUBLISH news "Selamat pagi, tim!"

redis-cli PUBLISH news "Selamat pagi, tim!" broadcasts the message. The subscriber receives three response lines: the message type, the channel name, and the message content. If there are no subscribers, PUBLISH returns 0 — the message is gone, not queued.

#Pattern-Based Subscription

To subscribe to many channels at once, use a wildcard pattern:

redis-cli PSUBSCRIBE news.*

PSUBSCRIBE news.* makes the subscriber receive all channels matching the pattern — for example news.tech, news.sport, news.weather. This is very practical for architectures that split channels by topic or region. Use PUNSUBSCRIBE to stop.

#Multi-Consumer Architecture

A single channel can serve many subscribers at once — for example one Redis instance with many WebSocket gateways each subscribing to a notification channel. When the backend publishes an event, all gateways receive it and forward it to clients. This is the core pattern of real-time broadcast at scale.

#Pub/Sub vs Streams

#When to Use What

This is an architectural decision that often confuses people. In short: Pub/Sub for broadcast that can afford to be lost, Streams for data that must survive and be processed with guarantees:

#Keyspace Notifications

#Hearing Key Changes

Keyspace notifications let applications listen to key change events — a key being set, expired, deleted, or modified. This feature is off by default; enable it with the notify-keyspace-events configuration:

redis-cli CONFIG SET notify-keyspace-events KEA

redis-cli CONFIG SET notify-keyspace-events KEA enables all events. The code string is categorized: K for keyspace events, E for keyevent events, A is an alias for g$lshzxe (all event types). There are two forms of notification:

• Keyspace channel (__keyspace@0__:mykey): the message contains the event name (e.g. set, expired).
• Keyevent channel (__keyevent@0__:expired): the message contains the key name affected by the event.

redis-cli SUBSCRIBE __keyevent@0__:expired

redis-cli SUBSCRIBE __keyevent@0__:expired listens for all keys expiring in database 0. When a key expires, the application receives its name — a perfect pattern for cleaning up caches or related state.

#Keyspace Notification Use Cases

• Cache invalidation: the application immediately knows when a cache key is deleted/updated and can sync related data.
• Session expiry: when a session expires, the application records logout activity or cleans up resources.
• Scheduled cleanup: the expired event replaces polling cron jobs.

Also note: enabling too many events (KEA) adds overhead per write operation. In production, enable only the events you really need, for example KE or a specific subset.

#Summary

Episode 8 equipped you with Pub/Sub for real-time broadcast and keyspace notifications for hearing key changes: SUBSCRIBE/PUBLISH, PSUBSCRIBE with patterns, the Pub/Sub vs Streams comparison, and notify-keyspace-events for expired events and invalidation.

Key takeaways:

• Pub/Sub is fire-and-forget: without subscribers, messages are lost.
• SUBSCRIBE is exclusive — you can't run other commands while subscribed.
• PSUBSCRIBE news.* subscribes to many channels with a wildcard.
• Use Streams if messages must be durable and processed with guarantees.
• CONFIG SET notify-keyspace-events KEA enables keyspace notifications.
• The __keyevent@0__:expired channel tells you which key expired.
• Don't rely on eviction notifications; enable only the events you need.

In the next episode, episode 9, we cover Transactions (MULTI/EXEC) & Optimistic Locking (WATCH) — how Redis runs several commands atomically, protects data from race conditions with WATCH, and pipelining techniques to reduce network round-trips. Get your terminal ready!