System design interview: design a collaborative editor

1. Clarify the requirements

Ask what kind of document it is and how people use it. Rich text, spreadsheets and drawings need different operation types, and "must work offline" changes the core algorithm.

• Functional: several people edit the same rich-text document at once; everyone sees others' edits, cursors and selections; edits made offline merge when the device reconnects; per-user undo; version history; owner, editor, commenter and viewer roles.
• Non-functional: every replica ends up with the same content (convergence); an acknowledged edit is never lost; your own typing feels instant; other people's edits appear within a few hundred milliseconds.
• Out of scope unless asked: comments and suggestions, search across documents, export formats.

2. Estimate the scale

These figures are assumptions picked for easy arithmetic, not measurements of any real product.

The conclusions: storage is not the problem; ordering many small writes and fanning them out quickly is. One document's traffic is tiny, so a single server per document is enough, which makes ordering easy.

3. Define the API

GET /api/v1/docs/{docId}
  returns: 200 { "version": 1203, "snapshot": { ... }, "role": "editor" }

WS  /api/v1/docs/{docId}/live?since=1203
  client -> server  { "type": "op", "clientId": "c42", "seq": 17, "baseVersion": 1203,
                      "ops": [{ "retain": 120 }, { "insert": "hello" }] }
  server -> client  { "type": "ack", "seq": 17, "version": 1204 }
  server -> others  { "type": "op", "version": 1204, "clientId": "c42", "ops": [ ... ] }
  both ways         { "type": "presence", "userId": "u9", "cursor": { "anchor": 125, "head": 125 } }

GET  /api/v1/docs/{docId}/history?from=1000&to=1204
POST /api/v1/docs/{docId}/permissions   { "email": "ana@example.com", "role": "commenter" }

Each client sends at most one unacknowledged batch at a time and buffers later edits until the acknowledgement arrives. That keeps the transformation logic on both sides small. clientId plus seq lets the server drop a batch it has already applied when a client resends after a reconnect.

4. Sketch the data model

Presence (who is here, where their cursor is) lives only in the session server's memory. Persisting every cursor move would multiply writes for data nobody needs tomorrow.

5. The core decision: OT or a CRDT

Both approaches make concurrent edits converge. They differ in how they describe a position in the text and in whether they need a central ordering point.

Operational transformation. Operations use integer positions relative to a specific version. When an operation arrives based on an older version, the server transforms it against each operation applied since, so it still means what the author intended. Take the text cat. Ana inserts s at position 3; at the same moment Ben deletes position 0. The server applies Ana's first, giving cats at version 1. Ben's delete was based on version 0; Ana's insert came after position 0, so the delete stays at 0, and the result is ats. Ben's client, which already shows at, receives Ana's insert transformed against his delete: position 3 becomes 2, giving ats. Both converge.

With a central server that fixes a single order, the transform function only has to handle two concurrent operations correctly. Without a central server, OT needs extra properties that are hard to get right, and several published peer-to-peer OT algorithms were later shown to diverge in some cases. That is why practical OT systems put a server in the middle.

CRDTs (conflict-free replicated data types). Each inserted character gets a permanent unique id, such as (replica id, counter), and an insert says "after the character with id X" rather than "at position 3". Deleted characters usually stay as tombstones so later operations can still refer to them. The merge rules are commutative and idempotent, so any two replicas that have received the same set of operations hold the same text, whatever the order. Operation-based CRDTs rely on the sync layer to deliver each operation in causal order (and to ignore repeats); state-based CRDTs merge whole states and tolerate any delivery order.

A reasonable default for an online-first product is OT with one session server per document, because the server is already the source of truth. If the interviewer stresses offline-first or peer-to-peer use, switch to a CRDT; the rest of the architecture barely changes, except that the server merges and relays instead of transforming. Neither approach understands meaning: if two people retype the same sentence differently, both edits survive and a human tidies up.

6. The architecture

1. 1Apply locallyThe client applies the edit to its own copy at once, then sends it with its base version.
2. 2OrderThe session server transforms the operation against anything newer than its base version and assigns the next version number.
3. 3PersistIt appends the operation to the log with a conditional write on (document, version) and only then acknowledges the author.
4. 4Fan outIt broadcasts the operation to the other clients, which transform it against their own unacknowledged edits and apply it.

7. Scale it and handle the hard features

• Shard documents to session servers. Use consistent hashing on doc_id or an explicit routing table with leases. One writer per document keeps ordering trivial; capacity grows by adding servers. See sharding strategies.
• Snapshots. Write a snapshot every 1,000 operations or 5 minutes (assumed tuning). Load is snapshot plus tail, and old operations can be compacted into named versions for history.
• Presence. Send cursor updates at most every 50 to 100 ms and transform cursor positions like operations (with a CRDT, anchor them to character ids). Drop a user's presence when their connection closes or a short timeout passes.
• Offline edits. The client keeps unsent operations in local storage with their base version. On reconnect it sends them; the server transforms them against everything since (OT) or merges them (CRDT). If the needed history has been compacted away, fall back to a three-way merge against a snapshot, and never drop the user's work silently.
• Undo. Undo is per user and never rewrites history. The client takes the inverse of the user's last operation, transforms it against everything applied since, and sends it as a new operation. With a CRDT, undo is a new operation that deletes what you inserted or restores what you deleted.
• Permissions. Check the role when a session opens and on every write. When a role is downgraded, the session server pushes the change and starts rejecting operations from that user at once.
• Very busy documents. For thousands of viewers, broadcast through a separate fan-out tier, cap simultaneous editors and batch operations.
• Regions. One session server per document means collaborators on another continent see edits a cross-region round trip later, often 150 ms or more. Place each document's server near most of its editors and move it when that changes. Consistency comes first here; see consistency and CAP.

8. What breaks, and what you do about it

9. Trade-offs to discuss

• OT or CRDT. OT is lighter on metadata and well proven with a central server; CRDTs remove the ordering point and handle offline merges, at the price of per-character metadata.
• Persist before broadcast. Persisting first adds a log write (a few milliseconds) to the collaborator's latency but means nobody sees an edit that could still be lost. Broadcasting first is faster and occasionally shows text that later disappears.
• Batch size. Sending every keystroke gives the smoothest remote view but the most messages; batching for 50 to 100 ms cuts message volume sharply at a delay people barely notice.
• Snapshot frequency. Frequent snapshots make loads and recovery fast but cost storage and write bandwidth.
• Rich text. Formatting spans (bold that two people extend at once) need their own merge rules in either model; name this as the next hard problem.

10. How to talk through it in the interview

• Walk through one tiny concurrent edit, like the cat example, on the whiteboard. It proves you understand the merge model.
• Say clearly which guarantee each piece gives: convergence from the merge model, durability from the log, ordering from the single session server.
• Keep presence separate and cheap, and say why.

Practicing this design with Natively

Run the walk-through as a mock interview: ask a friend to play the interviewer on a call, or read the prompt aloud yourself. Natively transcribes the conversation as it happens and can suggest talking points for each question as it comes in; comparing them with what you said is a quick way to spot gaps such as offline reconciliation or undo. If you sketch the OT example or the architecture, you can capture a screenshot of it and have Natively explain it. After the session, the transcript and notes show where you ran long and what you skipped.