Design a collaborative text editor

01Choose online collaboration and define saved

Design plain-text documents shared by several users, with simultaneous edits, permissions, cursors, undo and recovery after short disconnections. Exclude rich formatting, embedded spreadsheets and months of offline editing from the first design. Those requirements change the operation model and retained metadata, not merely the number of servers.

Two users open document D7 containing cat at version 20. A inserts X at position 1 while B inserts Y at the same position. Both edits should survive under a defined ordering rule. Replacing the entire document with cXat and later cYat loses A's work even if each database write is individually atomic.

Distinguish immediate local display from saved state. A keystroke appears locally as pending; saved means the service has durably accepted that identified edit. A lost connection may leave a usable local draft without permission to claim it is saved. Presence is another category: a cursor is a temporary hint and need not survive a restart.

Assume documents up to 1 MB, at most 100 active participants and a thirty-minute automatic reconnect window. Target same-region acceptance below 150 ms p95 and remote display below 300 ms p95 on connected, responsive peers under admitted load, both measured from edit submission. Using a merge algorithm and WebSockets does not prove the service meets those latency targets.

Clarify whether the editor is plain text or rich text, how many users share one document, and how long disconnected clients must merge automatically. This answer supports plain text, up to 100 active participants per document and a selected thirty-minute automatic reconnect window; longer gaps preserve drafts for explicit resynchronization.

02Functional requirements

1. Open and share documents. Create or retrieve plain-text documents and assign current read/edit permissions.

2. Edit concurrently. Accept identified inserts, deletes and supported undo operations while preserving concurrent edits under the chosen transformation rules.

3. Collaborate live. Display local pending edits immediately and distribute accepted edits and temporary cursor/presence information to authorized participants.

4. Reconnect and recover. Retrieve saved content, replay missing accepted versions and reconcile pending operations after short disconnections without applying an edit twice.

03Non-functional requirements

These are illustrative interview assumptions, not product facts or measured benchmarks. Confirm them before choosing components, then validate the completed design under the stated workload. Here p95 means the 95th-percentile latency: 95% of measured requests take no longer than that value. Report errors and rejected work alongside latency; a fast failure is not a successful outcome.

1. Document and fleet size. Limit a document to 1 MB and 100 active participants. Plan for one million connected users and 100,000 incoming edits/s across documents; benchmark a single hot document separately.

2. Latency. Target same-region durable edit acceptance below 150 ms p95 and display on connected, responsive peers below 300 ms p95, measured from submission under admitted load. Slow or disconnected peers use bounded buffers and replay; immediate local display is not a save acknowledgment.

3. Convergence and ordering. All clients applying the same accepted history must converge under the supported editing protocol. Give every accepted edit one stable identity and version; whole-document last-write replacement cannot satisfy this requirement.

4. Saved-state durability and reconnect. Accepted edits and operation identities survive application/coordinator restarts. Retain the transformation and retry history needed for thirty minutes of automatic reconnect; older drafts require explicit resynchronization. Database disaster tolerance depends on the selected replication/backup policy, not socket reconnection.

5. Authorization. Check current permission when accepting edits and serving snapshots or replay. Reject stale coordinators at storage and reject edits after revocation takes effect; previously downloaded text cannot be recalled.

04Complete one edit with a coordinator and durable log

Start with one application serving document APIs and WebSockets, backed by a transactional database. For each active document, a coordinator holds the accepted content in memory and uses a proven operational-transformation implementation. Operational transformation adjusts an incoming edit to account for concurrent edits accepted since its base version. It requires compatible rules on both client and server.

Follow A17 through the edit path:

1. A opens D7 at version 20, displays X locally and submits operation A17 with its base version.

2. The coordinator checks current edit permission and whether A17 already exists.

3. It transforms the operation against intervening accepted history, then transactionally appends the accepted edit and advances the document version.

4. Only after durable commit does it acknowledge A17 and broadcast the result.

Clients reconcile the accepted operation with their pending local operations. A's own acknowledgment removes its pending entry; it must not insert X a second time. A server restart rebuilds accepted content from a snapshot and subsequent operations. Lost broadcasts are repaired by replaying missing versions.

This baseline already needs a real editing library, persistent operations and a reconnect protocol. WebSockets only provide a low-latency connection; they neither merge conflicting edits nor recover a message that vanished before reaching a peer.

05Walk through two concurrent insertions

Positions in the example are zero-based: position 1 lies between c and a. A17 and B9 both describe edits based on cat at version 20. Suppose the selected library's tie-break rule places A's same-position insert first.

B had already displayed cYat locally. Its client transforms incoming A17 and its own pending edit consistently, preserving both letters and converging to cXYat. The rule makes clients agree on the text. It cannot know which word the users intended.

Deletes, overlapping ranges and undo need their own correct rules. Undo should reverse the selected edit using the library’s rules, preserving other users’ work where specified, rather than upload an old entire document. Choose one documented text representation for all clients. Byte offsets, UTF-16 code units, Unicode scalar values and visible grapheme clusters are not interchangeable; use the library's agreed units and conversion rules.

A worked insert example explains the mechanism but is not a complete algorithm implementation. Evaluate a maintained OT stack and its persistence adapter rather than treating this table as sufficient production code.

06Size active typing and peer delivery separately

Assume one million connected users, five percent currently typing and two operations/s per typist. That yields 100,000 incoming edits/s. At 200 bytes per operation, payload ingress is 20 MB/s before framing, indexes and replication. If sustained for a full day, the operation payload is about 1.728 TB; actual duty cycles must be measured rather than assumed constant.

Ten other participants receiving each edit create one million peer deliveries/s. Connection memory can also be significant: one million connections at an illustrative 32 KB each consume about 32 GB before process and encryption overhead. Moving sockets and fanout to gateways may matter before optimizing the storage engine.

A single document with 100 typists at two edits/s has 200 ordered edits/s and about 19,800 peer deliveries/s. Sharding other documents does not split this document's edit order. Measure transformation CPU and fanout separately before claiming a global shard count solves the hotspot.

Snapshots trade storage work for shorter recovery. A 1 MB snapshot every 1,000 edits on that hot document means a snapshot every five seconds, or 200 KB/s for that document alone. Use a replay-byte target and minimum interval rather than an unexamined count-only rule. Bound per-client queued bytes to prevent slow viewers consuming unlimited memory.

07Name operation identity, base and accepted version

Interfaces

These JSON examples show the worked insert and its acceptance. The selected editing library defines the actual operation encoding.

A17: client edit based on version 20

{
  "operationId": "A17",
  "baseVersion": 20,
  "operation": {
    "type": "insert",
    "position": 1,
    "text": "X"
  }
}

A17: acceptance after durable commit

{
  "operationId": "A17",
  "version": 21,
  "canonicalOperation": {
    "type": "insert",
    "position": 1,
    "text": "X"
  }
}

Stored records

Scope operation identity to the document and authenticated actor. A retry with identical content returns its original acceptance; the same ID with different content is an error. Check for an already accepted operation before rejecting its now-old base, because a lost acknowledgment does not turn a retry into a new unsupported edit.

The client keeps a pending-operation buffer, ideally persisted locally under a stated draft policy. The server retains enough accepted history for its advertised reconnect interval. Presence messages have session sequence and expiry but do not advance durable document versions. Merely knowing an actor ID or document URL does not grant access.

08Recover the gap between saved history and live messages

On open, return a snapshot and a fixed accepted upper boundary, such as version 22. If the snapshot is version 20, replay operations 21 and 22 to reconstruct that boundary. Newer edits can arrive through a subsequent replay or live subscription; they must not silently alter which operations the initial response promised.

Subscribe with the last applied version. The server must replay or buffer edits accepted between the initial read and live registration. Otherwise version 23 could be lost in the handoff. A client receiving version 24 while expecting 23 requests the gap before applying later positional operations.

After a brief disconnect, first obtain missing accepted history, then reconcile and resubmit pending edits with their original identities using the editing library's protocol. The server returns saved acceptances for duplicates. Arrival order between acknowledgment and broadcast should not cause the sender to apply its own insertion twice.

If a client predates retained transformation history, preserve its local draft and require an explicit resynchronization/merge workflow against current content. A snapshot of today's text does not reconstruct every old position shift. Advancing the supported history boundary is therefore a product decision, not a side effect of deleting old logs to save disk.

09Separate document ordering from sockets and fanout

Move WebSocket connections to gateways when connection count and outgoing traffic overwhelm the first process. Gateways authenticate sessions, enforce buffer limits and forward edits to the document owner. They broadcast accepted versions to subscribers but cannot declare an edit saved just because they received it.

Partition ownership by document. Different documents use independent coordinators and storage partitions, while D7 retains one accepted order. A routing directory chooses the coordinator; the durable append path remains the source of authority. Workers receiving D7’s edits at random would still need to agree on their order and transform them against that same history.

A replacement coordinator reconstructs D7 from durable content before accepting edits. Give ownership an increasing generation and check it at log append alongside the expected head version. If an old coordinator resumes after replacement, its stale generation is rejected by storage. Routing new clients elsewhere is insufficient because the old process may still hold open sockets and prepared writes.

If a transform was computed against head 21 but the append finds head 22, reload the intervening edit and recompute rather than appending the old transformed position blindly. Use the chosen library/adapter's supported concurrency controls and test the ownership boundary rather than implementing a second, inconsistent edit protocol around it.

10Keep recovery short without hiding snapshot assumptions

Create snapshots from a precise committed version so the saved content and advertised version agree. A simple baseline stores snapshot content and its version transactionally in the same database. The 1 MB document bound makes this a reasonable starting choice, avoiding a separate object-publication protocol in the first design.

After a snapshot at version 22, recovery starts there and replays operations after 22. Do not delete transformation history still required for supported pending edits merely because the visible text has a newer snapshot. A snapshot may restore the saved text without retaining the earlier edits needed to transform a reconnecting client’s pending work.

At larger historical volume, immutable snapshot objects plus database references can reduce database storage, but publishing, retaining and deleting those objects safely adds another protocol. Keep that extension explicit rather than compressing object lifetime guarantees into “use object storage.”

Preserve accepted operation and metadata transactions across application restarts; configure and test database replication for any additionally agreed storage-node or zone failure tolerance. Presence, gateway connections and in-memory content caches can be rebuilt; the log and operation identities cannot be treated as disposable. Backups cover accidental deletion or corruption replicated to every serving copy. A restore test should reconstruct exact accepted content and retry behavior, not merely find a snapshot file with the right name.

11Preserve drafts, permissions and accepted history

Check permission at edit acceptance, not only at socket establishment. Read permission also applies to snapshots and replay. Revocation cannot erase bytes a user already downloaded, so distinguish preventing new access from recalling past disclosure.

Test concurrent insert/delete/undo histories under different delivery orders and compare final accepted content. Add coordinator failure, duplicate operation IDs, lost acknowledgments and old-client reconnect. Before upgrading the editing library, replay representative histories through old and new versions and verify protocol compatibility.

Measure pending age, accepted-edit latency, remote-delivery delay, transform failures, replay bytes and buffer evictions. A responsive local cursor can hide a saving outage. Keep document text out of broadly accessible logs; IDs, versions and timing usually suffice for diagnostics.

12Check the design against its requirements

Use the numbered requirements to check the final design. FR refers to the functional list; NFR refers to the non-functional list. Performance rows specify tests still required, not achieved benchmark results.

13Rapid revision

Remember: The merge algorithm combines edits; the durable log preserves them. A socket does neither by itself.

Close by showing cat → cXat → cXYat, then lose A17's acknowledgment. Explain which component combines edits and which preserves the result. A CRDT is an alternative worth evaluating for extensive offline collaboration, with its own operation metadata and cleanup requirements; it changes the editing model rather than simply adding a component to OT.

Recall the key ideas

Answer from memory before opening each card. Explain why the choice works and what it costs. Revisit missed cards tomorrow.