Snapshot and Delta Sync over WebSockets

Most real-time screens are fed two ways: a snapshot (the full state, once) and a stream of deltas (what changed since). Getting them to agree is harder than it looks, and much harder when a user is editing the same data that’s streaming in. I spent a good part of 2026 on exactly this, building trading dashboards at a fintech.

The sync recipe

1. Subscribe first and buffer. Open the stream and queue deltas before you ask for the snapshot, so nothing slips through the gap between the two.
2. Load the snapshot. It should carry a sequence number (or version).
3. Drop buffered deltas older than the snapshot, apply the rest in order, then switch to applying deltas live.
4. Only ever apply newer values. Every update carries a sequence; anything stale or out of order is ignored.
5. Deltas need add, update and remove, not just update, or rows quietly linger.
6. A new snapshot resets the base. Don’t try to turn snapshots back into deltas on the client; that’s the server’s job.

It’s the same idea as replaying a log after restoring a backup, and closely related to how consensus systems keep replicas in step (Message Passing).

Editing while data streams: pristine and dirty

The real trap is a user typing into a cell while the server keeps updating it. The pattern that worked:

• Keep a pristine copy (the latest server state) and a set of dirty fields (the user’s edits).
• Incoming deltas update pristine, never a dirty field, so a local edit is never overwritten mid-thought.
• Clearing an edit falls back to pristine. Submitting sends the diff between edits and pristine.
• Reset goes back to the latest live state, not a stale copy from when the page loaded.
• After submitting, refetch or invalidate so the next snapshot is the source of truth.
• Keep edits in the same shape as the snapshot; mismatched shapes are where the bugs hide.

Implementation tips

• Apply deltas near the grid (as grid transactions), not at the app root, and batch them on a short interval (AG Grid Performance Patterns).
• Index rows in maps by id: O(1) lookups instead of searching arrays on every message.
• One owner per socket. A single provider holds the connection; components subscribe to slices, so re-renders don’t tear down subscriptions (Zustand Transient Updates).
• Split big payloads into entities. A large snapshot that changes by one field shouldn’t re-render the whole screen.

Related: WebSockets · Server-Sent Events (SSEs) · Finding React Re-render and Memory Leaks