advanced practice · system design prompt

Collaborative doc editor

Design a Google-Docs-style collaborative editor for 2-50 concurrent editors. Define how clients represent causality, choose OT or a specific CRDT family, explain the sync protocol, and work through two concurrent edits delivered in opposite orders.

The mechanism

Collaborative state needs an explicit notion of causality and a deterministic reconciliation rule. OT transforms concurrent operations against an agreed history; CRDTs design state or operations around algebraic merge laws so replicas converge despite reordering and duplication. Neither is universally simpler: choose from offline requirements, metadata and tombstone cost, server coordination, undo semantics, and the data structures the product needs.

Study Collaboration Systems

Expected evidence

Causality model + conflict algorithm + a worked merge showing that replicas reach the intended document state.

Try this drill in the practice workspace →

Hints when you need them

Name the invariant you need before choosing OT or a CRDT: convergence alone is not the same as preserving user intent.
Account for metadata growth, tombstones or garbage collection, offline duration, undo, and cursor presence.

Watch for these mistakes

Treating replica convergence as proof that concurrent edits preserve user intent
Calling CRDTs coordination-free while ignoring causal delivery, metadata compaction, tombstone garbage collection, or membership changes
Assuming every OT design requires one central server, or that every CRDT design has the same wire and storage costs
Replicating ephemeral cursor and presence state through the durable document history

Check the sources

Practice the same mechanism

Make three replicas converge

Browse all practice briefs