Realtime Collaboration on Sim

This separation is deliberate. Blocks, edges, and subflows have different update patterns and conflict characteristics. By storing them separately:

1. Targeted updates: Moving a block only updates positionX and positionY fields for that specific block row. We don't load or lock the entire workflow.
2. Query optimization: Different operations hit different tables with appropriate indexes. Updating edge connections only touches workflow_edges, leaving blocks untouched.
3. Separate channels: Structural operations (adding blocks, connecting edges) go through the main operation handler with persistence-first logic. Value updates (editing text in a subblock) go through a separate debounced channel with server-side coalescing—reducing database writes from hundreds to dozens for a typical typing session.

The server uses different broadcast strategies: position updates are broadcast immediately for smooth collaborative dragging (optimistic), while structural operations (adding blocks, connecting edges) persist first to ensure consistency (pessimistic).

Client-Side: Optimistic Updates with Reconciliation

Clients maintain local copies of workflow state in Zustand stores. When you drag a block or type in a text field, the UI updates immediately—this is optimistic rendering. Simultaneously, the client queues an operation in a separate operation queue store to send to the server.

The client doesn't wait for server confirmation to render changes. Instead, it assumes success and continues. If the server rejects an operation (permissions failure, conflict, validation error), the client reconciles by either retrying or reverting the local change.

This is why workflow editing feels instantaneous—you never wait for a network round-trip to see your changes. The downside is added complexity around handling reconciliation, retries, and conflict resolution.

The Operation Queue: Reliability Through Retries

At the heart of Sim's multiplayer system is the Operation Queue—a client-side abstraction that ensures no operation is lost, even under poor network conditions.

How It Works

Every user action that modifies workflow state generates an operation object: