Realtime Publish Alone Cannot Deliver Chat Room Notifications After Disconnects

Realtime publish alone is insufficient for delivering chat room notifications to clients that disconnect. Notifications sent during a user's absence will not be seen when they return. To ensure notifications are delivered even after a client disconnects, persist notifications in an inbox before publishing. Assign a monotonically increasing cursor within a clearly defined scope and let clients acknowledge what they have processed.

When clients reconnect, backfill all notifications after their acknowledged cursor. The realtime path provides fast delivery, but the inbox enables reliable recovery. In developer tool chat rooms, a browser can disconnect between a build mention and an engineer returning to the tab. A transport can transmit data while clients are connected, but it cannot guarantee that an absent client will later see an application event.

Realtime publish success is not an accurate indicator of user-visible notification outcomes. Instead, measure the progression of notifications through creation, acknowledgement, and recovery. The inbox pattern involves persisting notifications, signaling delivery, acknowledging receipt, and enabling recovery upon reconnection. Record four timestamps for each notification: inbox commit, publish attempt, client receipt, and acknowledgement.

Also note the reconnect cursor provided by the client and the highest cursor returned during backfill. These timestamps help trace the notification's journey and identify discrepancies between committed and acknowledged cursors. When designing the notification system, choose a durable boundary for records. In a transaction, insert the domain change and the notification inbox record, or derive both from the same committed event.

Publish only after the commit is successful. If publishing fails, the record remains available for later backfill. If publishing succeeds but the client disconnects before processing, the record remains available after the last acknowledged cursor. Implement at-least-once redelivery with deduplication based on notification ID. Exactly-once semantics can obscure the boundary between records and client connection states.

Provide a stable ordered page to clients by using per-user or per-room cursors, or a global cursor for simpler storage at the cost of potentially exposing unrelated traffic patterns. Pick the cursor scope based on the ordering promise and capacity plan accordingly. The provided Go interface defines the inbox boundary, including notification structure and store operations for appending, querying by cursor range, and acknowledging notifications.

The acknowledgement function should advance monotonically, preventing backward movement upon retries and ensuring a deterministic order for fetching pages. When reconnecting, clients authenticate, submit their last acknowledged cursor, request a bounded page, apply received records idempotently, acknowledge the highest contiguous cursor, and repeat until caught up with live delivery.

If live events arrive during backfill, buffer them by cursor or establish a server watermark before switching modes to avoid gaps or timeline reordering. Limit backfill responses to prevent overwhelming clients, especially when peak notification creation rates exceed their offline window capacity.