harshaRedis Pub/Sub is useful when live listeners need immediate notifications. Its delivery model also places a clear boundary on what an application can assume: messages are delivered at most once, and a disconnected subscriber can miss them. Redis documents this behavior explicitly.
That boundary matters when the notification describes something more consequential than a transient update.
Separate notification from truth
Imagine a worker finishing a document-processing job while the browser briefly loses its connection. If the completion message exists only in Pub/Sub, the browser may keep displaying “processing” after the work is done.
The worker did its job. The notification mechanism did what it promised. The application still failed to reconcile them.
A durable job record can resolve that mismatch. The live message tells the client to look; the record tells the client what is true. On reconnect, the client reads the current state instead of assuming that every transition was observed.
This pattern does not make Pub/Sub durable. It gives durability a separate home.
Decide which events require history
Some events are disposable. A progress indicator moving from 41 percent to 42 percent may not need to survive a disconnect if the latest state is available. A final result, permission change, or recorded operation may require stronger treatment.
I would classify events by the consequence of missing them, then choose delivery and storage accordingly. A single channel carrying everything can obscure those differences.
When replay is necessary, evaluate a durable event mechanism and its actual acknowledgment, retention, and consumer semantics. Do not label a system replayable merely because messages have IDs.
Reconnection is part of normal operation
Connections drop for ordinary reasons: mobile networks, suspended tabs, deployment changes, and intermediate infrastructure. A reconnection path is therefore a primary workflow, not an obscure exception.
Test a listener that joins late. Test one that disconnects just before completion. Test duplicate notifications if the surrounding application may generate them. The important result is whether the client converges on the correct state.
The design question is simple: if nobody hears the message, does the system still know what happened? For work that matters, I want the answer to be yes.