Design a Collaborative Editor: System Design Interview 2026

A collaborative editor combines real-time transport, durable synchronization, and a convergence algorithm. The transport resembles the gateway pattern from the chat-system design. Convergence means replicas that have incorporated the same accepted changes expose the same logical document—not that every merge preserves human intent, or that a client can remain offline forever after old history is compacted.

This walkthrough assumes the 6-step system design framework and applies it at senior-plus depth. It is Part 15 of an extended system design series.

Table of Contents

1. The Problem
2. Step 1 - Clarify Requirements
3. Step 2 - Estimate Scale
4. Step 3 - API and Data Model
5. Step 4 - High-Level Design
6. Step 5 - Deep Dive: CRDT vs Operational Transformation
7. Step 6 - Bottlenecks and Trade-offs
8. Undo, Invariants, and Security
9. Reference Architecture
10. Common Mistakes in the Interview
11. Quick Reference
12. Frequently Asked Questions
13. Sources
14. Related Articles

The Problem

We are designing a real-time collaborative editor: many users change a shared document, receive updates with low latency, can work offline within a supported window, and converge after exchanging all accepted changes. The product shape covers shared text, whiteboards, structured documents, and code workspaces, though their operation models differ substantially.

The senior framing is a convergence and intent problem on top of durable real-time sync. Operational Transformation (OT) and Conflict-free Replicated Data Types (CRDTs) are two major families, but the choice is not a generational contest and hybrids such as Eg-walker exist. The right design depends on document semantics, offline requirements, invariants, undo, memory, history, and the libraries the team can verify and operate.

Step 1 - Clarify Requirements

Functional requirements:

• Multiple users edit the same document concurrently.
• Every user sees every edit in near real-time.
• Accepted edits survive according to a defined durability/RPO policy; retries are idempotent.
• Concurrent edits converge without a raw source-control-style merge dialog, while product semantics still handle competing intent.
• Offline editing within a declared retention and compatibility window, with snapshot fallback for older clients.
• Cursor and selection awareness.
• Undo and history.

Out of scope for the algorithm deep dive: comments and suggestions, rich-media storage, and multi-petabyte archives. Authentication, authorization, tenant isolation, and permission revocation cannot be out of scope for the system: every join, sync, and update must enforce them.

Non-functional requirements:

• Real-time latency - a keystroke should reach other collaborators within ~100 ms.
• Tens to hundreds of concurrent collaborators per document.
• Strong eventual consistency - replicas that have seen the same operations are in the same state.
• High availability, including survival of brief network partitions.

The decisive questions are the convergence contract, intention policy, supported document operations, offline window, and server authority. For a CRDT, strong eventual consistency usually means replicas that have received the same set of updates reach the same observable state, under the algorithm's delivery assumptions. That does not imply byte-identical serialization, preservation of arbitrary cross-field invariants, or a guarantee that every deterministic merge feels correct to a user.

Step 2 - Estimate Scale

The following numbers are an interview scenario, not claims about a real product. Production sizing comes from measured serialized update size, active-document skew, runtime memory, TLS buffers, and fan-out.

Sessions. Assume 5 million concurrent connected editor sessions at peak. Multiple tabs and devices can create more connections than users, while many connected sessions are idle.

Operation rate. A worst-case first pass of 5 emitted updates/sec for all 5M sessions gives 25 million updates/sec. In practice clients batch keystrokes/transactions and only a fraction type simultaneously, so model active ratio, batch interval, document skew, and reconnect bursts. A hot document can be much more important than the global average.

Update bandwidth. If the assumed serialized update averages 50 bytes, 25M updates/sec is ~1.25 GB/sec before protocol, TLS, replication, and fan-out. Do not treat 50 bytes as a CRDT constant: encoding, batching, rich-text marks, dependencies, compression, and recipients determine the real number.

Document storage. Ten million active documents at an assumed 100 KB each is ~1 TB of logical state. Replicas, snapshots, indexes, operation/change history, attachments, audit retention, and deleted-content metadata add more.

The defining shape: a chat-scale connection layer, modest per-document throughput, document-level state where the algorithmic choice (OT vs CRDT) determines almost everything else.

Step 3 - API and Data Model

The session uses a persistent WebSocket (the Part 6 transport) with a handful of frame types:

The sync primitive depends on the algorithm. A centralized OT service can send a checkpoint plus revisions after it. Yjs-style CRDT sync can exchange state vectors and only the missing binary update; Automerge exchanges causal heads and missing changes. After compaction, incompatible schema, or an excessive offline gap, the server sends a fresh snapshot and carefully reapplies still-authorized local changes.

Step 4 - High-Level Design

flowchart TD
    A([User A]) <-->|WebSocket| GA[Gateway A]
    B([User B]) <-->|WebSocket| GB[Gateway B]
    C([User C]) <-->|WebSocket| GA
    GA --> DocOwn[Document Owner<br/>one per document]
    GB --> DocOwn
    DocOwn -->|durable append + checkpoint| Store[(Change History + Snapshots)]
    DocOwn -->|broadcast accepted updates| GA
    DocOwn -->|broadcast accepted updates| GB
    Reg[(Document Registry)] -.lookup owner.-> GA
    Reg -.lookup owner.-> GB

Figure 1. Gateways hold connections and route sessions to a document owner or shard. The owner authorizes, validates, durably appends, checkpoints, and broadcasts accepted updates. A centralized OT design also uses it as the revision and transformation authority; a CRDT does not require its order for convergence, but the owner still enforces product rules.

This concrete deployment assigns each active document to one fenced owner, similar to a per-conversation authority. In centralized OT, that owner assigns revisions and transforms operations. A CRDT can converge without that order, but an owner is still useful for durable acknowledgement, authorization, schema validation, rate limits, awareness fan-out, compaction, and invariant checks. Use a lease epoch or fencing token so two owners cannot both accept authoritative writes after a failover.

Step 5 - Deep Dive: CRDT vs Operational Transformation

This is the core. OT and CRDTs solve related convergence problems under different models; neither is a universal successor to the other, and some production systems use custom or hybrid algorithms.

Part A - The convergence problem

Two users start from hello world. Alice inserts X at position 5 while Bob inserts Y at position 3. Bob's local state becomes helYlo world. If Bob now applies Alice's original numeric position 5 literally, he gets helYlXo world; preserving Alice's original placement after hello requires position 6, producing helYloX world. Raw numeric positions do not carry enough concurrent context.

A correct design can transform operations against concurrent context (OT), use a replicated data type with deterministic merge rules (CRDT), or use a hybrid representation that reconstructs enough concurrent context during merge.

Part B - Operational Transformation

In the centralized OT design used here, every operation goes through the document owner. The server assigns a revision order; clients optimistically apply local operations and transform incoming or pending operations against concurrent context. OT itself is an algorithmic family, not a requirement that every topology have exactly one server, but a server-ordered stream makes the interview architecture easier to reason about.

The transform function is the heart of OT. Given two concurrent ops, it produces a new op with the same intended effect:

Insert("X", pos=5)  transformed against  Insert("Y", pos=3)
   --->  Insert("X", pos=6)        // because Y at 3 shifted everything right

sequenceDiagram
    participant A as Alice
    participant S as Server (OT)
    participant B as Bob
 
    Note over A,B: Both see doc "hello world"
    A->>S: Insert("X", pos=5) - rev 0
    B->>S: Insert("Y", pos=3) - rev 0
    Note over S: Server orders: Bob first, then Alice
    S->>B: ack Insert("Y", pos=3) -> rev 1
    S->>A: incoming Insert("Y", pos=3)
    Note over A: transform local pending against incoming<br/>still pos=5? no - shift to 6
    S->>A: ack Insert("X", pos=6) -> rev 2
    S->>B: incoming Insert("X", pos=6) -> rev 2
    Note over A,B: both converge to "helYloX world"

Figure 2. Operational Transformation on a concurrent edit. Both clients send to the server with the same revision; the server picks an order and transforms each operation against the others so positions stay correct. Alice's Insert at pos=5 becomes pos=6 after Bob's earlier insert at pos=3 shifts everything right - the transform function is what makes this convergence possible, and also what makes OT notoriously hard to get right.

OT can keep the materialized document compact because text operations commonly use positions and payloads, although servers still need revision history, pending-client context, undo metadata, and checkpoints. Transform correctness becomes difficult as the operation vocabulary grows from text insert/delete to marks, tables, embeds, moves, and schema-aware transactions. Centralized OT also couples online acceptance to the revision authority; decentralized OT variants exist, but add protocol complexity.

Part C - CRDTs

A Conflict-free Replicated Data Type defines update and merge rules so replicas that receive the same updates converge under the CRDT's assumptions. State-based CRDTs merge states with an algebraic join; operation- or delta-based designs may require causal delivery, dependency tracking, buffering, or idempotent update encoding. A common sequence-CRDT technique gives elements stable identities or logical positions and expresses insertion relative to existing structure rather than only a numeric offset:

Insert("X", after=id_7, before=id_8, id=(siteA, 42))

flowchart TD
    A["Doc: [h,id1] [e,id2] [l,id3] [l,id4] [o,id5]"]
    A --> Op1["Alice: insert X between id3 and id4<br/>new id (siteA, 42)"]
    A --> Op2["Bob: insert Y between id1 and id2<br/>new id (siteB, 31)"]
    Op1 --> Merge["Apply both - either order"]
    Op2 --> Merge
    Merge --> Final["Doc: [h,id1] [Y,(B,31)] [e,id2] [l,id3] [X,(A,42)] [l,id4] [o,id5]"]

Figure 3. CRDT insertions making order irrelevant. Each character has a globally unique ID, and inserts anchor between existing IDs rather than at numeric positions, so Alice's and Bob's concurrent inserts can be applied in either order and produce the same document. There is no transformation - operations commute by construction, which is why CRDTs need no central authority for convergence.

The real algorithm also defines a deterministic order when two inserts choose the same anchors and specifies what to do when a dependency has not arrived. Some libraries package updates that are commutative, associative, and idempotent—Yjs documents this for its binary updates—but that property should not be asserted for every raw operation in every CRDT. No central sequencer is required for CRDT convergence, although product servers still arbitrate authorization and invariants.

The cost depends on the CRDT. Sequence metadata, actor/version information, history, and indexes can make the in-memory representation larger than raw text. Some designs retain tombstones or other deletion metadata because concurrent or delayed updates may reference deleted structure. Compaction is a protocol decision: it needs causal stability, or a rule that sufficiently old replicas reload a snapshot before replaying authorized local work.

Use a maintained implementation such as Yjs or Automerge rather than inventing a text CRDT during an interview take-home. Product names require precision: Figma describes its main multiplayer model as CRDT-inspired but explicitly says it is not a true CRDT or one single CRDT; its server is authoritative. Its newer collaborative code layers use the hybrid Eg-walker algorithm. That is evidence that data shape and workload matter more than a fashionable label.

Part D - The comparison

Offline and multi-device requirements often make a CRDT library attractive because each replica can accept local changes and exchange missing updates later. That does not make catch-up trivial: dependencies, schema migrations, revoked access, compacted history, huge deltas, malicious updates, and semantic invariants remain. OT can also support offline editing when the system retains the revision context needed to transform or rebase pending work.

Part E - Hybrid and domain-specific approaches

The decision is not limited to classic OT versus a permanently materialized sequence CRDT. Hybrid algorithms can retain a compact sequential representation on the common path and reconstruct conflict-resolution state only when histories diverge. Figma's collaborative code layers use Eg-walker, which represents edits as a causal event graph and temporarily builds CRDT-like merge state for concurrent branches before discarding it. A visual canvas may instead use server-ordered last-writer-wins properties plus domain-specific validation, as Figma's main multiplayer system does. Start from the document's operations and invariants, then choose the algorithm.

Causality

Causality answers whether change B was created with change A in its history or whether the two were concurrent. A Lamport clock guarantees that A happens-before B implies L(A) < L(B), but the reverse is not true: two Lamport values alone cannot detect concurrency. Version/state vectors, explicit dependency hashes, or a causal change DAG record richer history and let peers request missing changes. Actor ID plus counter is a common unique operation identity, but identity, total-order tie-breaking, and causal context are separate jobs.

Consistency model

For a CRDT, strong eventual consistency means replicas that have applied the same updates expose equivalent observable state. It does not require byte-for-byte identical serialized storage. A centralized OT system instead converges clients on the server's accepted revision history. During a partition, a CRDT-capable client can keep accepting local changes; an OT client can also queue tentative work if the protocol supports later rebase. Neither algorithm automatically preserves arbitrary application invariants or user intent.

Unlike a generic multi-value register that exposes concurrent siblings to application code, a CRDT embeds deterministic resolution in its data type. “Automatic” means repeatable, not necessarily semantically desirable; a document schema still needs domain-specific rules for tables, references, permissions, and transactions spanning several fields.

Failure modes

• Connection drop. The client reconnects with its revision, state vector, or change heads and transfers missing durable updates. Awareness such as cursors is ephemeral and is re-announced rather than replayed as document state.
• Document-owner crash. A new fenced owner loads the last checkpoint plus durable tail. Clients retry unacknowledged updates idempotently and resync; an ACK must mean the documented persistence boundary was crossed.
• Convergence bug. Incorrect OT transforms, CRDT merge code, non-deterministic schema logic, or a malformed migration can all diverge replicas. Differential/property-based tests and sampled logical-state hashes are defenses, not proof from an acronym.
• Metadata or history growth. Track materialized size, retained updates, undo history, and deleted-content metadata. Compact only with a safe frontier or force old replicas through snapshot sync.
• Long offline session. Either algorithm may face a large upload and a large remote delta. Apply quotas, stream/batch validation, preserve a local recovery copy, and define behavior when permissions, schema, or retention changed while offline.
• Split brain. Two document owners can accept incompatible authoritative histories. Lease epochs/fencing and conditional durable writes are required; a timeout alone is not fencing.

Multi-region

Each document can have a home region for durable ownership, validation, and efficient fan-out. Cross-region collaborators connect to nearby gateways that forward updates home. A multi-writer CRDT topology can accept changes in several regions and converge, but global permissions, unique constraints, retention, abuse controls, and schema invariants may still require coordination. Home failover needs fencing, a stated RPO/RTO, and a decision about whether clients may edit locally while the authority is unavailable.

Evolution path

The algorithm choice is expensive to change because stored history, client formats, undo, and sync protocols depend on it, but it is not literally one-way. Migrations usually checkpoint every document into a canonical representation, introduce a new protocol/version boundary, and prevent old clients from writing after cutover. Pick deliberately and keep explicit compatibility/versioning from day one.

Observability

Track accepted and rejected updates, durable-ACK latency, fan-out latency, active documents, hot-document skew, reconnect delta size/time, dependency-buffer depth, snapshot fallback rate, owner epochs, compaction lag, per-document memory/history, and slow consumers. Sample logical-state hashes only over a canonical representation; raw serialized bytes may differ while state is equivalent. Any unexplained logical divergence is a serious incident.

Step 6 - Bottlenecks and Trade-offs

• Per-document throughput is bounded by its owner, validation, durable append, and fan-out. Most documents are cool, but a public or AI-edited document can be a hot shard.
• Representation overhead depends on the chosen engine, schema, batching, retained history, undo, and compaction—not only the raw text size.
• OT complexity grows with the operation vocabulary and every transform pair that must preserve intent.
• CRDT complexity moves into data-type design, causal sync, deterministic conflict rules, invariants, and safe history/deletion compaction.
• Offline catch-up can be expensive for either approach and must handle permission/schema changes, quotas, and snapshot fallback.
• Awareness fan-out is ephemeral but can dominate traffic when cursors and selections update at animation-frame frequency; throttle and coalesce it separately from durable edits.

Undo, Invariants, and Security

Collaborative undo should reverse the current user's logical transaction, not restore an old whole-document snapshot that erases other people's later work. Group keystrokes into transactions, retain the metadata the chosen engine needs, and test undo/redo across concurrent inserts, deletes, formatting, moves, and remote edits. Redo semantics are a product decision, not a free inverse operation.

Convergence does not preserve arbitrary invariants. Concurrent moves can create cycles, a table can violate its schema, and two users can compete for a supposedly unique name. Model operations at the right semantic level, validate transactions, and decide which invariants require an authoritative server or coordination. Rejected optimistic work needs a visible rollback/reconciliation path.

Authenticate the connection and authorize every join, snapshot, delta, and update. Re-check membership when permissions change; remove active sessions and reject queued offline edits after revocation according to policy. Bound decompressed update size and dependency depth, rate-limit durable and awareness traffic separately, validate schema versions, encrypt in transit/at rest, isolate tenants, and keep sensitive document content out of logs. CRDT convergence is not a security boundary: a malicious peer can construct validly encoded but unauthorized or resource-exhausting updates.

Reference Architecture

The pattern this problem teaches, reusable beyond editors:

A versioned document model plus a verified OT, CRDT, or hybrid convergence engine; durable, idempotent synchronization; ephemeral awareness; and explicit rules for undo, invariants, permissions, compaction, and old clients.

flowchart LR
    subgraph Choice["Convergence engine"]
        direction TB
        OT["Operational Transformation<br/>transform concurrent context"]
        CRDT["CRDT<br/>deterministic replicated merge"]
        Hybrid["Hybrid / domain-specific<br/>causal graph or server rules"]
    end
    subgraph Common["Shared infrastructure"]
        direction TB
        Conn[Persistent connection layer]
        Snap[(Durable history + checkpoints)]
    end
    Choice --> Common

Figure 4. OT, CRDT, and hybrid engines can share connection, persistence, checkpoint, and sync infrastructure. Their update format, causal context, compaction, and authority model differ, so the common boxes do not make their guarantees interchangeable.

The same shape recurs in shared whiteboards, local-first applications, multiplayer state, and replicated configuration. The important interview move is to state the actual operation model and convergence/invariant contract instead of naming an algorithm and assuming the rest.

Common Mistakes in the Interview

• "Last-write-wins on the document" - silently loses changes and is not what any production editor does.
• Lock-based editing - one user at a time, terrible UX, irrelevant to the actual problem.
• Confusing OT and CRDT, or saying “we use CRDT” without naming the concrete data types, update format, delivery assumptions, and merge rules.
• Underestimating OT's transform-function complexity by treating "just shift positions" as the whole story.
• Treating offline merge as trivial, with no dependency sync, permission/schema change, quota, compaction, or snapshot-fallback story.
• Assuming every CRDT has per-character tombstones, or offering garbage collection without a causal-stability/old-replica policy.
• Claiming Lamport timestamps detect concurrency; they order events but do not encode the full causal frontier.
• Using raw document snapshots for undo, which can overwrite collaborators' later edits.
• Treating convergence as authorization or invariant enforcement, allowing an encoded update merely because it merges deterministically.

Quick Reference

Frequently Asked Questions

What is the difference between CRDT and Operational Transformation?

OT transforms an operation against concurrent context; many practical designs use a server revision stream, though centralization is not the definition. A CRDT supplies deterministic replicated merge/update rules that converge under its protocol assumptions. They are algorithm families, and hybrid designs also exist.

How do collaborative edits avoid conflicts?

They guarantee deterministic convergence, not the absence of semantic conflict. OT transforms positions and operations; sequence CRDTs use stable identities or logical positions plus deterministic concurrent-update rules. The product still defines transaction boundaries, schema invariants, competing intent, and user-visible reconciliation.

Why does a collaborative editor need causality tracking?

Causality separates a dependent change from a concurrent one and identifies missing prerequisites. Use state/version vectors, change heads, or explicit dependency graphs. A Lamport timestamp preserves happens-before order in one direction but cannot by itself determine concurrency.

How does offline editing work in a collaborative editor?

The client durably queues local transactions and its sync frontier. On reconnect it exchanges revisions, state vectors, or change heads, transfers missing updates, validates permissions/schema, and converges. If retained history is insufficient, it reloads a snapshot and carefully reapplies still-authorized local work.

What is a tombstone in a CRDT and why does it exist?

Some sequence CRDTs retain metadata for deleted elements because delayed or concurrent operations may reference them. Not every CRDT uses literal tombstones. Safe compaction requires a causal-stability frontier or a policy that older replicas reload from a snapshot.

Does a CRDT editor need a central server?

Not for convergence itself. Servers are still common for authentication, authorization, durable storage, discovery, fan-out, retention, rate limits, compaction, and application invariants. A production server is often more than a passive relay.

Sources

• Yjs: Document Updates
• Yjs: Y.Doc and garbage-collection controls
• Automerge documentation: offline, network-agnostic synchronization
• Figma: How Figma's multiplayer technology works
• Figma: Making multiplayer more reliable
• Figma: Building collaborative Code Layers with Eg-walker
• Shapiro et al.: Conflict-free Replicated Data Types

Related Articles

• System Design Interview Problems: A Senior's Roadmap - the full series index and pattern library.
• System Design Interview Guide: The 6-Step Framework - the method this walkthrough applies.
• Design a Chat System - Part 6; the persistent connection layer reused for editor sessions.
• Design a Key-Value Store - Part 14; vector clocks and sibling resolution, the conflict-detection toolkit applied differently here.
• Design a Unique ID Generator - Part 13; the (siteId, counter) ID scheme that CRDTs lean on.
• Design a Distributed File System - Part 16; the chunked-replicated storage that sits underneath a persistent op log.

This is Part 15 of an extended system design series. Next: Design a Distributed File System.

Frequently Asked Questions

What is the difference between CRDT and Operational Transformation?

Operational Transformation adjusts an operation against concurrent operations and their context so its intended effect is preserved; many practical OT systems use a server-ordered revision stream, but centralization is an architecture choice rather than the definition of OT. A CRDT is a replicated data type with deterministic merge rules that make replicas converge after they receive the same updates, under that CRDT's delivery assumptions. CRDTs are a family of designs, not simply 'OT without a server', and hybrid algorithms also exist.

How do collaborative edits avoid conflicts?

Collaborative algorithms guarantee a deterministic converged state; they do not eliminate semantic conflict or guarantee every user's intention. OT transforms edits against concurrent context. Sequence CRDTs commonly use stable element identities or logical positions plus deterministic rules for concurrent inserts and deletes. The editor must also define atomic transaction boundaries, schema invariants, undo semantics, and what users see when two valid changes compete.

Why does a collaborative editor need causality tracking?

Causality distinguishes an edit that depends on another edit from a truly concurrent one. Version vectors, state vectors, dependency hashes, or a causal change graph can identify missing predecessors and drive delta sync. A Lamport clock preserves happens-before ordering but, by itself, cannot tell whether two events are concurrent and does not record the full set of operations a producer had seen. Missing dependencies must be requested or buffered, never silently discarded.

How does offline editing work in a collaborative editor?

A client persists local edits and a sync frontier while offline. On reconnect, peers exchange revisions, state vectors, or change heads to transfer only missing changes, deduplicate them, satisfy causal dependencies, and converge. OT and CRDT systems can both support offline work, but with different rebase, metadata, and protocol costs. Retention, schema upgrades, permission revocation, and garbage collection require a snapshot fallback and an explicit maximum-offline policy.

What is a tombstone in a CRDT and why does it exist?

Some sequence CRDTs retain metadata for a deleted element so later or concurrent operations can still resolve references; that retained marker is commonly called a tombstone. Not every CRDT represents deletion this way, and optimized libraries may compact deleted content. Safe reclamation needs a causal stability frontier or a rule that replicas older than the compaction point must reload a snapshot, otherwise a long-offline replica may still reference removed metadata.

Does a CRDT editor need a central server?

A CRDT does not require one central sequencer for convergence, and peers can synchronize directly. Production editors commonly still use servers for authentication, authorization, durable storage, discovery, fan-out, rate limits, retention, and invariant enforcement. A server may reject an otherwise convergent update that violates permissions or document rules, so calling it only a passive relay is often too weak.