A realtime event tells a connected client that something changed. A persisted notification records that a user-visible item exists, its subject and recipient, status, source event, creation time, and read or action state after disconnects and restarts.
Choose the durable object before choosing the transport
Ask whether the user must see the item later, count unread items, mark it read, open the underlying object, or prove that the product created it. If yes, model a durable notification or derive a durable feed from authoritative domain events. The broker carries change signals; it should not become the only record that the user-visible event existed.
A useful notification row includes a stable identifier, recipient or audience, source event, subject type and identifier, presentation category, creation version, read or dismissed state, and a deduplication key. Store only the minimum content needed for the product. Sensitive message bodies can remain in the authoritative domain object while the notification stores a safe reference.
Make delivery and product state different measurements
Broker acknowledgement means the provider accepted a publish request under its documented semantics. Client receipt means one connection observed the event. Neither alone proves that a durable notification exists, that the interface rendered it, or that the user read it. Record those states separately so operational dashboards do not turn transport success into a product claim.
Test creation and retrieval without an active socket, then test a live push as an acceleration path. A reconnecting client should fetch authoritative unread state and reconcile duplicates. Retention, deletion, and read-state ownership need explicit rules, especially when several devices or tabs can update the same notification.
Where the service stops
Reality Contact, LLC repairs the bounded application delivery path, but does not warrant a third-party provider, guarantee uninterrupted delivery, certify security or compliance, or work on emergency, medical, life-safety, or other consequential alerting systems. The buyer approves the authoritative event and expected interface states, controls provider accounts and production release, reviews limitations, and decides whether to deploy or extend the repaired path. This is application reliability engineering; it does not replace legal, security, compliance, safety, medical, or professional advice. The service does not work on emergency or life-safety alerts and does not guarantee uninterrupted delivery or a third-party provider's availability.
Sources: Firebase Realtime Database offline capabilities; Pusher Channels connection states.