Real-time collaboration

The phrase "real-time" gets used loosely. Marketing copy treats it as a synonym for "fast." Engineers who have built a collaborative editor treat it as something narrower: changes made by one participant appear on every other participant's screen within a perceptual budget — roughly 100 milliseconds for cursor movement, a touch more for text edits — and the document never visibly diverges, even when the network temporarily can't deliver an update.

Both halves of that definition matter. The latency budget is the easy part to grasp. The consistency guarantee is the hard part to engineer. A naive design that simply broadcasts every keystroke to every peer will satisfy the latency budget on a good network and fall apart on a bad one — duplicated characters, lost edits, two clients drifting into different versions of the same document over hours of normal use. Real-time collaboration is the engineering work that closes that gap.

The standard a working editor has to hit is also stricter than most teams realise. It is not enough for the document to be eventually consistent. It must be visibly consistent during the session — every participant should be able to point at any character on screen and have it mean the same thing to every other participant — and it must survive a participant going offline mid-session and reconnecting later without losing the edits they made while disconnected. Those properties are what distinguish a real collaborative editor from a chat window that happens to render code.

Inside a working collaborative editor there are not one but two real-time systems, and they are almost completely independent. Understanding that they are separate is the first conceptual unlock for anyone new to the field.

The first system synchronises the document. It carries the text, the structure, the cursor positions, the selection ranges — every artefact of the shared workspace that needs to outlive any individual participant's session. That data has to be durable, has to converge across all peers regardless of network conditions, and has to survive any of them going offline. This is the system that CRDTs were designed for, and it is the layer where Yjs lives in ShareCode's stack. The deep-dive on how the editor handles sync goes into the data structures and the wire protocol in detail.

The second system carries the human channel — voice and video during a pair-programming session, screen share, the live audio feed that turns two people typing into one conversation. That system has the opposite requirements. It does not need durability; nobody wants their video archive replayed. It does need low latency, far lower than the document layer, and it needs that latency to hold up across a continent. WebRTC is the standard built for exactly that workload, and the architecture explainer in this topic walks through the SDP, ICE, and signaling pieces that make it work.

The two systems share an architectural shape — both have participants, both need to handle late joiners gracefully, both have an awareness protocol that signals who is present — but they use different protocols, different libraries, and different operational models. When something feels wrong inside a collaborative editor, the first diagnostic question is which of the two systems is failing. The fix for a desynced document and the fix for a frozen video stream have almost nothing in common.

Real-time collaboration is older than most developers realise. The first commercial collaborative editor that achieved meaningful adoption was Instant Update, shipped in 1991. Google Docs launched in 2006 and ran on Operational Transformation, an approach invented in academic papers in the late 1980s and refined heavily during Google's first decade of running it in production. CRDTs as a coherent body of work landed in 2011 with the INRIA paper that gave the field its name and its proofs of correctness.

This matters for two reasons. The first is that the protocol choices you make when you build a collaborative editor today are not free. Operational Transformation is still in production at Google, still works, and still requires a central server that arbitrates every edit. CRDTs trade that central server for a more complex per-character data structure, and they work without coordination — which is what makes them suitable for offline-first editors, for peer-to-peer collaboration, and for the kind of low-trust environments where you cannot assume the server is always reachable.

The second reason is that the literature has matured. Most of the hard problems in real-time collaboration — conflict resolution under network partition, intent preservation across concurrent edits, garbage collection of tombstones, fast resync after a disconnect — have published solutions. The work of building a new collaborative editor in 2026 is mostly the work of selecting which of those solutions to adopt, not the work of inventing new ones. The library choices, the data structure choices, and the wire protocol choices that ShareCode makes all sit on top of that literature.

It is easy, working inside this topic, to forget what the technology is for. The protocols exist because people work together. Real-time collaboration is the engineering substrate; pair programming, mob programming, remote teaching, technical interviews, and live debugging are the workloads it has to carry.

Those workloads are where the design pressure comes from. Pair programming, in particular, is the workload that exposes most of the rough edges. A cursor delay of 150 milliseconds is invisible during a code review and unbearable during a pair-programming session — the same latency that disappears into the rhythm of reading becomes a stutter the moment two people are taking turns at the keyboard. A presence indicator that takes 5 seconds to update is fine for a shared dashboard and disastrous when one participant needs to know whether the other is still in the room.

The two pair-programming posts in this topic cover this from both sides. The beginner intro is for developers who have never paired before and want to know what driver/navigator actually means, what equipment they need, and how to run a first session without it feeling awkward. The advanced post is for teams that already pair regularly and want to move past the basics into ping-pong with TDD, strong-style, mob programming with a rotating driver, and asymmetric pairing for onboarding. Both posts assume the underlying tooling works; this pillar is the layer that explains why that tooling has to work the way it does.

The team-level case for collaborative coding sits in its own post — the seven concrete benefits that show up in code quality, defect rates, onboarding time, and team communication. That post is the one to share with a manager who is sceptical about the time investment. The other posts answer the technical "how;" that one answers the organisational "why."

Every real-time collaborative system has roughly the same failure modes. They show up in different forms depending on the stack, but the underlying causes recur. Recognising them is half the work of debugging when a session goes wrong.

The first failure mode is silent divergence — two clients drift apart because an edit was applied on one side and not the other. In an OT system this is a transform bug; in a CRDT system it is almost always a missing update, which is why state vectors and resync protocols are load-bearing. The sync deep-dive covers how Yjs handles this through its state vector mechanism and why the resync after a dropped connection is usually a single round trip rather than a full document re-download.

The second failure mode is the cold-join problem — a new participant connects mid-session, and the question is how to get them caught up without freezing the editor for everyone else. The CRDT answer is to ship them the current state and a small replay; the OT answer is to put them on the live operation stream and replay from a checkpoint. Both approaches work; both have tail-latency cases that the production posts in this topic call out specifically.

The third failure mode is the media layer falling over while the document layer is fine. This is the most disorienting one for developers new to the area, because the editor visibly works — text edits propagate, cursors move, presence is correct — but the voice or video has frozen, and the natural instinct is to suspect the sync layer. The architecture explainer for WebRTC walks through the seven production mistakes that cause this specifically: misconfigured TURN, missing ICE candidates, codec negotiation failure, signaling that didn't survive a tab reload, and the subtler bandwidth-estimation cases.

Diagnosing real-time bugs is a discipline of its own. The first move is always the same: split the layers. Document desync goes to the sync deep-dive; media stalls go to the WebRTC explainer; weird presence behaviour usually sits between them, in the awareness layer.

The five posts in this topic do not have to be read in any particular order — each one stands on its own — but there is a path through them that compounds best for most readers.

Start with the team-level benefits post if you are deciding whether to invest in collaborative tooling at all. It is short, non-technical, and the right one to read first if you have not yet committed to the idea. If you are already sold on collaboration as a practice, skip it and come back later.

Move next to the beginner intro to remote pair programming. It is the practical foundation: what the workflow actually looks like, what equipment matters, and how to avoid the social awkwardness that kills first sessions. Even experienced developers who have not paired remotely before benefit from reading it.

Then take the WebRTC architecture explainer or the real-time sync deep-dive depending on which side of the stack you are working on. The two are largely independent. If you are integrating video or screen-share into a tool, read WebRTC first. If you are building or extending a collaborative editor, read the sync deep-dive first.

Close with the advanced pair-programming post. It assumes you have run a few pairing sessions already and want to move past the basics; reading it before you have the lived experience to ground it in tends to feel abstract. Read it after a month or two of regular pairing and the patterns will land.