Hi Greg,
We have two mechanisms for the state we use. The first one is web sockets for our multiplayer features like keeping our real-time cursors for multiplayer smooth.
For the document state (the circuit document) we are using Google's Firestore to keep the state synced across users. One of the problems we encountered is that documents can become quite large and always sending the whole latest states can even cause state issues by overwriting other changes if they are made at the wrong time. So we added some custom logic to always keep a full document ready for users who do the first load to be quick, and once you loaded the document you directly get the updates in granular changes synced as patch set itself. This allows users to locally jump back and forth in the time since each patch is essentially like an atomic change committed by the user and tracked in the version history.
For the document state (the circuit document) we are using Google's Firestore to keep the state synced across users. One of the problems we encountered is that documents can become quite large and always sending the whole latest states can even cause state issues by overwriting other changes if they are made at the wrong time. So we added some custom logic to always keep a full document ready for users who do the first load to be quick, and once you loaded the document you directly get the updates in granular changes synced as patch set itself. This allows users to locally jump back and forth in the time since each patch is essentially like an atomic change committed by the user and tracked in the version history.