Open a Google Doc with a coworker. You both start typing in the same paragraph. Somehow, your edits merge seamlessly -- no data loss, no weird glitches. It feels like magic, but under the hood it is one of the hardest problems in distributed systems: making concurrent writes to shared state converge to the same result regardless of network delays or operation order. This pattern shows up more often in interviews than you might expect. Any system where multiple users modify shared state simultaneously -- the [Slack](/learn/system-design/questions/slack) question with concurrent message edits, the [Online Chess](/learn/system-design/questions/online-chess) question where two players submit moves against the same board, even the [Crossword Puzzle](/learn/system-design/questions/crossword-puzzle) question where multiple solvers fill in the same grid -- needs some form of collaborative conflict resolution. ## Why Naive Approaches Fail The core problem is deceptively simple. Two users start with the same document and make edits at the same time. Their edits travel over the network and arrive at different times. If you just apply each edit as it arrives, the result depends on arrival order, and the two users end up with different documents. You cannot solve this with simple locking (one user edits at a time) because it destroys the real-time experience. You cannot solve it with last-write-wins because you would silently discard edits. You need an algorithm that preserves every user's intent and guarantees all clients converge to the same document state. Two algorithms have emerged to solve this: Operational Transformation (OT) and Conflict-free Replicated Data Types (CRDTs). ## Operational Transformation (OT) OT is the older approach, battle-tested at Google scale since 2006. The idea: when two operations are generated concurrently, a **transformation function** adjusts one operation's parameters based on the effect of the other so both can be applied in any order and still converge. Here is a concrete example. The document is `"Hello"`. User A inserts `"X"` at position 0, producing `"XHello"`. Concurrently, User B deletes the character at position 1 (the `"e"`), intending `"Hllo"`. If User B's delete arrives at User A's client after the insert, position 1 is now `"H"` instead of `"e"` -- the wrong character gets deleted. OT solves this by transforming User B's operation: since User A inserted a character before position 1, User B's delete position shifts from 1 to 2. Both clients converge to `"XHllo"`. The critical constraint: OT requires a **central server** that acts as the single source of truth for operation ordering. All clients send their operations to the server. The server assigns each operation a sequence number, transforms it against any concurrent operations it has already processed, and broadcasts the result. This is the same server-authoritative model used in the [Online Chess](/learn/system-design/questions/online-chess) question, where the server validates and orders all game moves to prevent conflicting board states. Google Docs uses OT. It works, it scales, and decades of production experience have ironed out the edge cases. The downside: the transformation functions grow complex as you add more operation types (text formatting, table edits, embedded objects), and you cannot edit offline because every operation needs the server to determine its position in the global sequence. **See it in practice:** The [Pushing Realtime Updates](/learn/system-design/design-patterns/pushing-realtime-updates) pattern covers WebSocket-based architectures that OT relies on for low-latency operation delivery. The [Dealing with Contention](/learn/system-design/design-patterns/dealing-with-contention) pattern explores other strategies for handling concurrent writes to the same resource. ## CRDTs (Conflict-free Replicated Data Types) CRDTs take a fundamentally different approach. Instead of transforming operations after the fact, they design data structures where concurrent operations are **commutative** -- the order of application simply does not matter. Apply operation A then B, or B then A, and you get the same result. No server coordination required. For text editing, the key insight is assigning each character a **unique fractional ID** that determines its position. Instead of saying "insert X at position 3" (which is fragile -- positions shift as other users edit), you say "insert X with ID 0.15, which sorts between ID 0.1 and ID 0.2." These IDs are stable across all clients, so concurrent inserts never conflict structurally. This means CRDTs support **offline-first** workflows. A user can disconnect, keep editing, and when they reconnect, their changes merge automatically with everyone else's. No conflict resolution dialog, no manual merging. The data structure guarantees convergence mathematically. The trade-off is memory. Every character carries metadata (its unique ID, the client that created it, a logical timestamp). Deleted characters are often kept as "tombstones" rather than truly removed, because other clients might reference them. For a large document, this metadata overhead can be significant. Libraries like Yjs and Automerge have gotten much better at compressing this overhead, but it is still higher than OT's lean operation log. **See it in practice:** The [Distributed Counters](/learn/system-design/questions/distributed-counters) question is essentially a CRDT problem -- each node increments its own counter locally, and totals merge by summing. The [Event Sourcing and CQRS](/learn/system-design/design-patterns/event-sourcing-cqrs) pattern shares the idea of modeling state as a sequence of operations that can be replayed and merged. ## OT vs CRDT: Which One to Choose The choice depends on your architecture constraints and whether offline support matters. For an interview, a good default answer is: use OT if you already have a server-centric architecture and do not need offline support, use CRDTs if you want offline-first or peer-to-peer capability. Either way, mention the trade-offs -- interviewers care more about your reasoning than which one you pick. ## The Full Architecture Whether you choose OT or CRDTs, the overall system architecture looks similar. Clients connect via persistent WebSocket connections (not HTTP polling -- editing operations are too frequent and latency-sensitive for request-response). A collaboration server processes operations, and a document store persists the state. ### WebSocket Routing with Consistent Hashing For OT-based systems, all editors of the same document **must** connect to the same collaboration server, because that server holds the authoritative operation sequence in memory. A consistent hash ring maps each document ID to an owning server. When a user opens a document, the WebSocket gateway hashes the document ID and routes the connection to the correct server. If the owning server fails, the consistent hash ring reassigns the document to another server, which loads the latest state from the document store and picks up where the failed server left off. This is the same consistent hashing pattern used in the [Distributed Caching](/learn/system-design/design-patterns/distributed-caching) pattern for routing cache requests to the right node. For CRDT-based systems, the routing constraint is relaxed -- since CRDTs do not need a central authority, any server can accept operations and merge them. But in practice, most CRDT deployments still route all editors to the same server for lower latency on presence updates and cursor positions. ### Presence and Cursor Tracking Seeing where other users are in the document -- their cursor position, text selection, and whether they are actively typing -- is what makes collaborative editing feel alive. This **presence data** is ephemeral: it changes with every keystroke and is meaningless after the session ends. Presence updates piggyback on the same WebSocket connection used for document operations. They are broadcast to all editors of the same document but never persisted to the database. The collaboration server holds presence state in memory only. If the server restarts, clients simply re-send their cursor positions -- no data loss, just a brief flicker. ### Persistence and Version History Document state is persisted to a durable store (PostgreSQL, S3, or a purpose-built document database). The tricky question is **how often** to persist. Saving on every keystroke would overwhelm the database. Saving too infrequently risks losing edits if the server crashes. A common strategy: persist a **snapshot** of the document every N operations or every T seconds (whichever comes first), and keep an **operation log** of all operations since the last snapshot. On crash recovery, load the latest snapshot and replay the operation log. This is the same append-only log pattern used in [Event Sourcing and CQRS](/learn/system-design/design-patterns/event-sourcing-cqrs) and in write-ahead logs discussed in [Scaling Writes](/learn/system-design/design-patterns/scaling-writes). **See it in practice:** The [ChatGPT](/learn/system-design/questions/chatgpt) question handles concurrent edits to conversation history when a user sends a follow-up message while the model is still streaming a response. The [Remote Dev Box](/learn/system-design/questions/remote-devbox) question requires shared terminal and file state across multiple connected clients -- essentially a collaborative editing problem for code. The [Slack](/learn/system-design/questions/slack) question needs real-time presence indicators (typing indicators, online status) using the same WebSocket-based broadcast pattern described here. ## Common Interview Scenarios Collaborative editing concepts appear in interview questions even when the question is not explicitly about document editing. When you encounter these questions, you do not need to implement OT or CRDTs from scratch. What matters is demonstrating that you understand the fundamental problem (concurrent writes to shared state), the two main solutions (OT for server-centric, CRDTs for offline-first), the WebSocket-based architecture, and the trade-offs between them. **Related patterns:** The [Pushing Realtime Updates](/learn/system-design/design-patterns/pushing-realtime-updates) pattern covers the WebSocket and SSE infrastructure that collaborative editing depends on. The [Pub-Sub Messaging](/learn/system-design/design-patterns/pub-sub-messaging) pattern provides the fan-out mechanism for broadcasting operations to all editors. The [Idempotency and Exactly-Once Delivery](/learn/system-design/design-patterns/idempotency-exactly-once) pattern is relevant because duplicate operations (from network retries) must not corrupt the document -- both OT and CRDTs handle this through operation IDs and version vectors.