System Design · advanced

Collaboration Systems

Causality, OT, CRDT merge laws, and offline conflict resolution.

system-designsystem-design-cases

Mental model

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.

How to study Collaboration Systems

Begin by restating the mental model in your own words, then connect it to a concrete system you have built or operated. Name the mechanism, the constraint it addresses, and the trade-off it introduces. Use System Design Primer, A Conflict-Free Replicated JSON Datatype (Kleppmann & Beresford), Local-first software: you own your data, in spite of the cloud to check details, but close the source before writing your explanation. Retrieval is the learning step; rereading is only preparation.

Next, compare Collaboration Systems with Consensus. Ask what changes in correctness, latency, resource use, operability, and failure recovery. Complete Make three replicas converge, Collaborative doc editor and preserve the command, input, output, and one failed attempt as evidence. Finish by explaining the idea without jargon to someone who has not studied the track.

Proof of understanding

  • Explain the mechanism from first principles and identify the state it reads or changes.
  • Give one situation where the concept is the right choice and one where it is not.
  • Predict a realistic failure mode before running the drill, then compare the prediction with evidence.
  • Connect the result to a roadmap or build artifact instead of treating the concept as isolated trivia.

Where it matters

Collaborative editors, offline-first applications, replicated JSON documents, multi-device state sync, geo-replicated counters and sets, and local-first productivity tools.

Common 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

Learn from primary sources

Practice and explain it back

Make three replicas converge

Implement mergeGCounter(left, right) and valueGCounter(state). A grow-only counter stores one non-negative count per replica; merge takes the maximum count for every replica, and value sums the merged counts. Your merge must converge when updates arrive in different orders and remain unchanged when the same state is delivered twice.

Expected evidence: Three independently updated replicas converge to the same {a:2,b:3,c:4} state and value 9 regardless of merge order.

Open the interactive drill →

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.

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

Open the interactive drill →

Review prompts

  • Why is convergence alone insufficient when choosing OT or a CRDT for collaborative editing?

Build evidence

Use a roadmap capstone to turn this concept into working evidence.

Prerequisites

Related concepts

Learning paths