Live Poll State for Late Joiners: Snapshot and Diff Without Trusting Clients

The recommended method for delivering poll state to late joiners is to maintain a server-owned snapshot of the current poll state, along with a monotonically increasing revision number. When a client joins late, it should first request the most recent snapshot. Subsequent changes are then sent as diffs, only when the revision number received matches the expected next revision.

This approach ensures the client's view of the vote totals remains accurate and prevents an untrusted browser from asserting incorrect data. The server owns the canonical poll data, including the question, options, counts, and revision number. The client receives the snapshot immediately upon connection and then subscribes to an ordered stream of patches to bring its view up to date.

If any gaps appear in the sequence, the client should request a new snapshot. The primary benefit of this design is its simplicity in providing a coherent view of vote totals for late participants.

To send a snapshot plus diff to late joiners using Node.js, the server should structure its data structure to include the current snapshot, revision number, poll question, available options, and counts of each option. When a vote is recorded, the server updates the counts for the selected option, increments the revision number, and then sends a diff message containing the updated counts and actor information (in this case, the server).

The client does not need to provide any participant identifiers in the diff message, as the server handles authentication and authorization.

In the event of a revision gap, the client should keep track of the last received revision number and, upon receiving a diff, compare the 'from_revision' field to this value. If they don't match, the client knows it has missed some updates and should request a fresh snapshot to reset its state and continue from the correct revision. This process incurs a small round-trip cost but ensures the client's view remains consistent with the server's state.

For recovery from a revision gap, the client should pause rendering the current view and request a fresh snapshot. Once the snapshot is received, the client applies the diff to update its state and resumes normal operation. This simple recovery mechanism balances the need for accurate state with the practical concerns of bandwidth and operational overhead.

When implementing this pattern, it's critical to measure performance metrics such as snapshot latency, the frequency of diff-to-snapshot recoveries, and the age of the oldest connected client. Monitoring these metrics can help identify performance bottlenecks and alert administrators to rising gap rates, which could indicate issues needing further investigation.

In terms of transport, WebSockets are ideally suited for this use case due to their bidirectional nature and support for server pushes. Server-Sent Events are a simpler alternative for one-way updates, while WebRTC data channels could be considered for peer-to-peer sessions, though they still require a server for authentication, authorization, and recovery processes. Regardless of the transport chosen, the snapshot/diff pattern remains consistent and is not dependent on the specific transport used.

This approach is particularly efficient for scenarios where the state is not excessively large or does not change at extremely high frequencies, as it minimizes the amount of data that needs to be transferred and reduces the risk of bandwidth issues. For more complex state management or high-frequency changes, a specialized replicated log or partitioned state management might be necessary, but for most marketplace sessions, this simple snapshot/diff mechanism provides a robust and scalable solution.