Real-time collaborative editing definition

Real-time collaborative editing lets several people type into the same document at once and see each other's changes appear almost immediately, with no locking, no submit step, and no manual conflict resolution. It works only when the editor sends descriptions of what changed rather than the whole document. In Sanity, the Studio emits field-level patches that the Content Lake applies and then redistributes over a listener connection to everyone else in the document, so two editors can work in the same paragraph without one overwriting the other.

What makes editing count as real-time collaborative editing?

Real-time collaborative editing qualifies as such when three properties hold at once. The first is concurrency without locking: every participant edits a local copy of the document in a non-blocking way, so nobody waits for anyone else to release it. The second is convergence: once everyone stops typing, every copy shows an identical document. The third is low-latency propagation: changes are synchronized continuously as people type, which removes the window in which conflicts can form rather than automating the cleanup afterward.

Convergence is not a marketing word here. It is a formal requirement in the collaborative editing literature, defined alongside causality preservation in the CC consistency model introduced by Ellis and Gibbs in 1989, and later extended into the CCI model, which adds intention preservation, meaning the effect of your edit still matches what you meant after it has been merged with someone else's. The Wikipedia article on operational transformation covers both models.

It is worth reading real-time collaborative editing as a concurrency-control strategy first and a user interface feature second. Avatars and live cursors are the visible surface. The merge model underneath is the part that either works or quietly loses somebody's paragraph.

How does real-time collaborative editing actually merge concurrent edits?

Real-time collaborative editing merges concurrent edits by exchanging small descriptions of individual changes, then reconciling them so that every copy of the document ends up the same. There are two well-established algorithm families for doing this, plus other approaches that reach similar guarantees.

Operational transformation (OT) rewrites an incoming operation against the operations a client has already applied. The classic example, given on the Wikipedia OT page, is one person inserting a character at position 0 while another deletes the character at index 2. The insert shifts everything right, so the delete has to be transformed to index 3 before it is applied, or the wrong character disappears. OT was pioneered by Ellis and Gibbs in the GROVE system in 1989, and in 2009 it was adopted as a core technique behind the collaboration features in Google Wave and Google Docs.

Conflict-free replicated data types (CRDTs) take a different route. Instead of transforming operations against history, they encode identity and ordering into the data structure itself, so the order in which updates arrive stops mattering. That makes peer-to-peer and offline scenarios easier at the cost of extra metadata. Sun and colleagues examine where the two families genuinely differ, and where they are commonly conflated, in Real Differences between OT and CRDT for Co-Editors.

Neither family is required by the definition. They are implementations of it. Microsoft's Fluid Framework, for instance, is documented as relying on Total Order Broadcast rather than OT or CRDT.

How is real-time collaborative editing different from locking, autosave, and version control?

Real-time collaborative editing differs from locking, autosave, and version control in where and when reconciliation happens. Each of the three is regularly described as collaboration, and none of them provides simultaneous editing on its own.

Document locking, sometimes called check-out and check-in or co-authoring with reservations, gives one editor exclusive access to a document, a field, or a paragraph while everyone else waits or watches. Some content systems implement this at field level, disabling an input for other users while somebody is typing in it. That is serialized editing with good manners, not simultaneous editing.

Autosave removes the save button. It does not make two concurrent writers converge. Autosave that sends the whole document on a timer, with last write winning, is precisely how one editor silently erases another's work.

Version control in the Git sense also handles concurrent change, but it defers reconciliation to an explicit merge step performed by a human, and it operates on committed snapshots rather than keystrokes. Real-time collaborative editing reconciles continuously, operation by operation, with no merge step exposed to the user at all.

The contrast with asynchronous collaborative editing is the cleanest of the set. As Wikipedia puts it, asynchronous editing means each user must typically submit, update, and, if conflicts occur, merge their edits by hand. The delay is what creates the conflicts. Real-time editing closes the window instead of improving the conflict dialog.

Is presence the same thing as real-time collaborative editing?

No. Presence is the awareness layer that sits on top of real-time collaborative editing, and it is not the same capability. Presence means avatars showing who else is in the document, live cursors showing where they are typing, selection highlights, and sometimes follow mode. It answers "who is here?", not "whose version wins?".

Presence is frequently shipped alongside real-time collaborative editing, and it is often what people picture when they hear the term, which is why the two get conflated. But presence alone merges nothing. A product can show you three colored cursors in a paragraph and still overwrite that paragraph when the second person saves.

Real-time content delivery is a third thing that shares the word. Live preview and live APIs push content out to a website or app as it changes, so readers and editors see fresh data. Real-time collaborative editing synchronizes concurrent writers of the same document. A system can have either one without the other, and the two are built from different machinery.

How does Sanity implement real-time collaborative editing?

Sanity implements real-time collaborative editing by moving fine-grained change descriptions rather than whole documents, and the sequence is documented publicly. The Studio loads a document from the Content Lake. As people edit their local version, the Studio emits precise, machine-readable descriptions of exactly what changed, called mutations. Those mutations go to the server, which applies them directly to the stored document. The server then distributes them to anyone else working in that document at the same time, and each collaborator's Studio applies them to its local version, so everything stays in sync.

That model is why Studio input components are built around patches instead of whole field values. The documented patch operations are set, setIfMissing, unset, insert, inc, dec, and diffMatchPatch, the last of which applies text changes using Google's diff-match-patch algorithm. Sanity's own guidance is that patches should be as fine-grained as possible and should avoid targeting array elements by index, because indices move when somebody else reorders the list. Traditional editors read a document, edit a local copy, and send all the content back, and Sanity's docs say plainly that this model breaks down as soon as you are collaborating with someone else.

The read side runs over Server-Sent Events. Clients subscribe to a listener endpoint with a GROQ query and receive mutation events carrying the document ID, the transition, the identity of the user making the change, the mutations themselves, the result, and revision IDs. Events can arrive out of order, so a careful client reassembles them by comparing previousRev and resultRev. On the write side, mutations are grouped into transactions that are atomic and ACID compliant, every transaction is recorded in a transaction log exposed through the document history API, and listeners are notified once a transaction commits. The same listener API is available to any application, not only the Studio.

Sanity is the Content Operating System for the AI era, and this sits squarely in its first pillar, modeling your business: because content is stored as structured fields rather than opaque blobs, changes can be expressed, merged, and audited at field level instead of at document level.

Last updated: September 13, 2026