Real-Time Collaboration Features: Building Multiplayer Editing Like Figma or Notion

“

Meerako — Dallas, TX engineers building real-time, multiplayer collaboration features.

Watching multiple cursors move live across a Figma canvas, or seeing a Notion document update as a teammate types, feels effortless as a user — which is exactly why teams consistently underestimate how hard it is to build correctly. Real-time collaborative editing touches some of the genuinely hard problems in distributed systems: conflict resolution, ordering, and consistency, all with latency requirements tight enough that the experience needs to feel instant.

The reference implementation is instructive here. Figma runs its multiplayer layer through a cluster of Rust servers, where each collaborative document gets its own dedicated server process and every editor of that document connects to that same process over WebSockets — and notably, Figma didn't pick either pure Operational Transformation or a textbook CRDT; it built a custom hybrid tuned to its specific canvas data model. That's worth internalizing before you start: even the company most associated with "solved" real-time collaboration didn't reach for an off-the-shelf answer, because their document model (a design canvas, not text) had different needs than the libraries most teams should actually use. For nearly everyone building a collaboration feature in 2026, the practical starting point is a production CRDT library, and the two leading ones have both improved substantially in the last year — Yjs now sees roughly 920K weekly downloads with 17K GitHub stars as the production default, while Automerge shipped a Rust-based rewrite that cut its processing time for 260,000 keystrokes down to about 600ms, a dramatic improvement from its earlier performance profile.

This guide covers why naive sync approaches fail, how CRDTs actually solve the conflict-resolution problem, what presence requires as a separate system, and how to scope a realistic first version instead of trying to build Figma's decade of engineering in one release.

• Why naive "last write wins" sync breaks down for collaborative editing.
• How CRDTs and Operational Transformation solve conflict resolution, and which library fits which use case in 2026.
• What presence (cursors, selections, live avatars) actually requires.
• The realistic scope, timeline, and infrastructure cost for a first version of a collaborative feature.

The obvious first approach — save the document, broadcast the new version to other clients — breaks immediately once two people edit at the same time: whoever's save arrives last silently overwrites the other's changes, with no merge and no warning. Real collaborative editing needs a fundamentally different approach that can merge concurrent edits from multiple users without losing anyone's changes.

CRDTs (Conflict-free Replicated Data Types) are data structures specifically designed so concurrent edits from multiple sources can always be merged deterministically, without central coordination — each client can apply changes locally and sync eventually, guaranteed to converge to the same state. Libraries like Yjs and Automerge implement production-ready CRDTs specifically for building collaborative applications, and are the practical starting point for most teams rather than implementing CRDT logic from scratch.

Operational Transformation (OT), the older approach (used historically by Google Docs), transforms each operation against concurrent operations to maintain consistency — powerful, but generally harder to implement correctly than working with an existing CRDT library, which is why most new collaborative features in 2026 default to CRDTs.

The choice between the two leading libraries has gotten more nuanced as both have matured. Yjs remains the pragmatic default for most product teams: the largest ecosystem of editor bindings (ProseMirror, Tiptap, CodeMirror, Monaco), no WebAssembly overhead affecting bundle size, and the deepest track record in production. Automerge has closed much of its historical performance gap with a Rust core, and it's the stronger pick specifically when version history is a product feature you want to expose to users — Git-like branching, merging, and change attribution are built into its data model in a way Yjs doesn't natively provide. A newer entrant, Loro, benchmarks as the fastest of the three in raw operations per second but has a much smaller production footprint (roughly 12K weekly downloads versus Yjs's 920K) — worth watching, not yet the safe default for a team that needs battle-tested reliability. For most SaaS teams building their first collaborative feature, start with Yjs unless document history is explicitly part of your product's value proposition.

Beyond merging document content, collaborative tools need presence — showing who's currently viewing or editing, live cursor positions, and current selections. This runs over a real-time transport layer (WebSockets, typically) separate from the document sync itself, broadcasting lightweight, frequent, ephemeral state (cursor position updates many times a second) that doesn't need the durability or conflict-resolution guarantees the document content itself needs. Figma's architecture is instructive here too — presence and document sync both ride over the same WebSocket connection to a per-document server process, but they're handled as logically distinct data streams with very different durability requirements, which is a pattern worth copying even at much smaller scale.

Persistent WebSocket connections change your infrastructure profile in ways a typical request-response API doesn't. You need connection-aware load balancing (sticky sessions or a routing layer that keeps a document's collaborators on the same backend process), a strategy for reconnection and state recovery when a connection drops, and — if you're self-hosting the sync layer rather than using a hosted CRDT backend — capacity planning for long-lived connections rather than short request bursts. Hosted options (Liveblocks, PartyKit-style edge sync, or a managed Yjs backend) can meaningfully shortcut this for a first version, trading a per-seat or per-connection cost for not having to operate the sync infrastructure yourself; that trade is usually worth it until you have a specific, proven reason to self-host.

The full feature set of Figma or Notion's collaboration took years to build — Figma's own engineering blog documents ongoing architecture investment even now, including a March 2026 shift in how component instance updates propagate through large design systems, delivering 40-50% faster updates in that specific workflow. That's a company with a decade of dedicated multiplayer engineering still actively refining the system. A realistic first version for most SaaS products scopes down deliberately: basic concurrent editing with CRDT-backed conflict resolution for the core content, simple presence (who's online, maybe live cursors), and a defined, honest boundary around what's not yet supported (complex nested structures, granular permission-aware collaboration) rather than attempting the full scope at once.

A realistic build timeline for a well-scoped first version — core CRDT-backed sync for one primary content type, basic presence, and offline reconnection handling — typically runs 6 to 10 weeks for a team already comfortable with the frontend framework in question, using an established library rather than custom conflict resolution. Extending that to granular permissions, rich presence (live avatars, follow-mode, commenting threads tied to live cursor position), and multiple collaborative content types easily doubles that scope.

The most expensive mistake is treating conflict resolution as a "we'll figure it out later" detail rather than the foundational architectural decision it is — retrofitting CRDT-based sync onto a system built around simple document saves is a substantially harder rewrite than architecting for it from the start. A second common mistake is under-scoping the offline and reconnection story — real users lose connectivity constantly, and a collaborative feature that corrupts state or silently drops edits on reconnect will erode trust faster than almost any other bug class, precisely because users have been trained by tools like Google Docs and Notion to expect this to just work. A third is neglecting permission-aware collaboration until late — if certain users should only view or should only edit specific fields, that needs to be designed into the sync layer's data model from day one, not bolted on after the fact.

Standard QA processes tend to miss the failure modes that actually matter for collaborative software. Concurrent-edit conflicts, network partition and reconnection behavior, and race conditions between presence updates and document changes rarely show up in a single-user manual test pass. Effective testing here means deliberately simulating multiple concurrent editors — including ones with artificially degraded or intermittent connections — and asserting that the document converges to the same final state regardless of the order operations arrive in. Property-based testing, where you generate large numbers of randomized concurrent edit sequences and verify convergence, catches classes of bugs that scripted test cases reliably miss. Teams that skip this and rely only on manual "two browser tabs" testing tend to discover their edge cases in production, from real users with genuinely flaky connections — which is a far more expensive place to find them than a CI pipeline.

We build on established CRDT libraries (Yjs is our default starting point, with Automerge when document history is a genuine product requirement) rather than implementing conflict resolution from scratch — that's a solved, thoroughly-tested problem not worth re-solving — and focus our custom engineering effort on the parts genuinely specific to your product: what's being collaborated on, how presence integrates with your existing UI, and how the feature scales with your actual concurrent-user patterns.

Real-time collaborative editing is a genuinely hard engineering problem disguised as a simple feature — but modern CRDT libraries have made building it dramatically more tractable than it was even a few years ago, with both Yjs and Automerge shipping meaningful performance improvements recently. The right approach uses proven libraries for the hard conflict-resolution problem, scopes the first version honestly against what teams like Figma took years to build, and focuses custom engineering effort on what's actually specific to your product.

Building a collaborative feature into your product? Let's architect the sync layer right.