Design Real-Time Notifications Without Mistaking Delivery Signals for Business State

Learning outcomes

AtlasMart's final Chapter 16 design must satisfy two requirements simultaneously: online dashboards should react quickly, and no order state transition may depend on a notification being delivered. The architecture therefore separates authoritative state, a replayable event, and a best-effort signal.

1. Three layers, three different jobs

The order Hash answers “what is true now?” The Stream answers “what durable application events were recorded and can be replayed?” The Pub/Sub channel answers “which connected clients should wake up now?” Keeping those contracts separate makes disconnect loss harmless to correctness: a missed wake-up can be repaired by state read or Stream replay.

2. Commit durable state before publishing the hint

A robust sequence changes authoritative state and records the durable event first. Then it publishes a lightweight hint. If PUBLISH fails or reports zero live subscribers, the order is still correct and the event remains replayable. If the durable write fails, do not publish a success hint.

HSET atlasmart:ch16:l5:order:{1001} status paid version 1 updated_at 2026-09-06T12:00:00ZXADD atlasmart:ch16:l5:events:{1001} '*' event_id evt-1001-1 order_id 1001 version 1 status paidPUBLISH atlasmart:ch16:l5:notify:1001 '{"order_id":"1001","version":1}'HGETALL atlasmart:ch16:l5:order:{1001}XRANGE atlasmart:ch16:l5:events:{1001} - +# PUBLISH recipient count may be zero; state and event still prove the committed transition.

3. Version the signal so stale deliveries are harmless

Pub/Sub can be duplicated by overlapping subscriptions or application retries, and a client can process an older notification after newer state exists. Put an entity ID and monotonically meaningful application version in the hint. The receiver compares that hint with its local version, then re-reads authoritative state when necessary. The payload should not contain secrets merely because the channel is restricted.

HSET atlasmart:ch16:l5:order:{1001} status shipped version 2PUBLISH atlasmart:ch16:l5:notify:1001 '{"order_id":"1001","version":1}'HGET atlasmart:ch16:l5:order:{1001} versionHGET atlasmart:ch16:l5:order:{1001} status# A version=1 notification is stale; the authoritative record already says version=2 shipped.

4. Reconnect policy is part of the cache/notification protocol

On Pub/Sub reconnect, assume the gap may contain missed signals. The receiver should invalidate any state whose freshness depends on uninterrupted signals, re-fetch a checkpoint/snapshot, and—where exact missed events matter—replay the Stream from a stored ID/group state. Do not silently keep a local cache “because Redis reconnected successfully.”

5. Least privilege spans commands, keys, and channels

Redis ACLs authorize key patterns and Pub/Sub channel patterns separately. Since Redis 7.0, new Redis Open Source ACL users are restrictive for Pub/Sub channels by default. The temporary user below can read/write only Chapter 16 order/event keys and publish/subscribe only Chapter 16 notification channels. It does not receive CONFIG, ACL, or all-channel access.

ACL SETUSER ch16-app reset on '>AtlasMart-Ch16-App-Lab-Only-2026' '~atlasmart:ch16:l5:*' 'resetchannels' '&atlasmart:ch16:l5:notify:*' '+@read' '+@write' '+@pubsub' '+ping' '+client|setname'ACL GETUSER ch16-appACL DRYRUN ch16-app PUBLISH atlasmart:ch16:l5:notify:1001 probeACL DRYRUN ch16-app PUBLISH other:tenant:notify probe# First DRYRUN should be allowed; second should be denied by channel pattern.# PSUBSCRIBE ACL matching has stricter literal-pattern considerations; test the exact pattern your client will use.

6. Cluster and Sentinel change reconnect/routing, not the source-of-truth rule

In Redis Cluster, place state and Stream keys that must participate in one transaction/function into the same slot using a deliberate hash tag such as {1001}. Ordinary Pub/Sub is globally propagated across the Cluster; sharded Pub/Sub can reduce Cluster-bus fan-out when channel slot design matches traffic. Under Sentinel or Cluster failover, clients can disconnect; therefore the post-reconnect reconciliation step remains mandatory.

7. Durable processing stays idempotent

If a background service consumes atlasmart:ch16:l5:events:{1001} through a Stream consumer group, it can be redelivered after a crash before acknowledgment. Use event_id or a business idempotency key so replay is safe. The Pub/Sub hint should never be used as the idempotency ledger.

XRANGE atlasmart:ch16:l5:events:{1001} - +XINFO STREAM atlasmart:ch16:l5:events:{1001}# If a consumer group is added, XPENDING/XACK become processing-state evidence.# The Pub/Sub channel itself exposes no historical event IDs.

8. Failure-injection matrix before production

9. Observability that matches the contract

Measure publication rate and recipient counts only as live transport signals. Pair them with subscriber reconnect count, callback latency, output-buffer indicators, local queue depth, state-reconciliation failures, Stream lag/pending counts where durable processing exists, and entity-version mismatch counts. Alert on correctness-recovery failures rather than on “PUBLISH returned zero” alone; zero can simply mean no dashboard is online.

10. Cleanup and rollback

Delete only the Chapter 16 state/event fixtures and the temporary ACL user. No global notification configuration is changed in this lesson. If the user is still connected, deleting/disabling it may disconnect or deny subsequent commands; close test clients first.

UNLINK atlasmart:ch16:l5:order:{1001} atlasmart:ch16:l5:events:{1001}ACL DELUSER ch16-appACL USERS# Verify ch16-app is gone and no unrelated user/config was changed.

11. Production judgment and chapter synthesis

The safe architecture is intentionally asymmetric: durable state and replayable events carry correctness; Pub/Sub carries immediacy. Use explicit versions, idempotency, bounded retries/backoff, reconnection reconciliation, least-privilege channel ACLs, and topology-aware routing. If event retention/scale/independent failure domains exceed Redis operational goals, move the durable-event role to a purpose-built broker while keeping the same state-versus-signal separation.

12. Chapter summary and bridge

Chapter 16 separated live signals from durable processing. Pub/Sub is excellent for ephemeral fan-out when missed messages are recoverable; keyspace notifications are similarly lossy hints; Streams add replay and consumer state; external brokers may add broader event-platform capabilities. Chapter 17 moves underneath those mechanisms to persistence—RDB snapshots, AOF, fsync, rewrite, and crash recovery—where “data exists in Redis” must be translated into a tested recovery envelope.

Authoritative references

• Redis Open Source 8.10 release notes
• Redis Pub/Sub
• Redis Pub/Sub use case
• Redis Pub/Sub with redis-py
• PUBLISH
• SUBSCRIBE
• PSUBSCRIBE
• UNSUBSCRIBE
• PUNSUBSCRIBE
• SSUBSCRIBE
• SPUBLISH
• SUNSUBSCRIBE
• PUBSUB CHANNELS
• PUBSUB NUMSUB
• PUBSUB NUMPAT
• PUBSUB SHARDCHANNELS
• PUBSUB SHARDNUMSUB
• Redis keyspace notifications
• Redis subkey notifications
• CONFIG GET
• CONFIG SET
• CLIENT LIST
• CLIENT SETNAME
• Redis client output-buffer limits
• Redis Streams
• Redis streaming use case
• XADD
• XREADGROUP
• XPENDING
• XACK
• Redis ACLs
• ACL SETUSER
• ACL DRYRUN
• Redis Cluster specification
• Redis replication
• Redis Sentinel
• Redis persistence
• redis-py documentation
• redis-py 8.1.0 on PyPI
• Redis licenses