System Design Problems
Design Google Docs
Google Docs enables multiple users to edit the same document simultaneously with changes visible in real-time. The system must resolve concurrent edits without conflicts, maintain document consistency, and handle hundreds of simultaneous collaborators.
- Real-time Collaboration â Changes visible to all users within 100ms
- Conflict Resolution â Operational Transformation ensures consistency
- Offline Support â Continue editing offline; sync when reconnected
The core challenge is Operational Transformation (OT): transforming concurrent operations so they produce the same result regardless of execution order.
Requirements
Functional Requirements
- Multiple users can edit the same document simultaneously
- Changes appear in real-time (within 100ms)
- Cursor position visible for all collaborators
- Edit history with ability to undo/redo
- Comments and suggestions
- Offline editing with sync on reconnect
- Document sharing with permissions
Non-Functional Requirements
- Latency: Changes visible in < 100ms
- Consistency: All users see the same document state
- Scale: 100 concurrent editors per document
- Durability: Never lose edits
- Availability: 99.99%
Back-of-the-Envelope Estimation
Operational Transformation
OT Properties
Insert Operation Transformation
Delete Operation Transformation
High-Level Architecture
Detailed Design
Operation Model
Operation = {
type: "insert" | "delete" | "retain",
position: int,
character: char (for insert),
version: int, // Base version this op was created from
client_id: string, // Who created this op
timestamp: long
}
Server-side OT Flow
- Client sends operation with base version V
- Server receives operation
- Server transforms operation against all operations after version V
- Server applies transformed operation to document
- Server increments version to V+1
- Server broadcasts transformed operation to all other clients
- Server persists operation to operation log
Client-side OT Flow
- User makes local edit â create operation with current local version
- Apply operation locally immediately (optimistic update)
- Send operation to server
- Receive transformed operation from server
- Adjust local state based on server's transformed operation
Version Vector
Version Vector: {
client_a: 15, // Client A has applied 15 ops
client_b: 12, // Client B has applied 12 ops
client_c: 18 // Client C has applied 18 ops
}
Persistence Strategy
| Component | Storage | Reason |
|---|---|---|
| Operation Log | Append-only log | Durable, enables replay |
| Document Snapshots | Periodic snapshots | Fast document loading |
| Operation Buffer | In-memory (Redis) | Recent ops for transformation |
Scaling OT Servers
Practice Exercises
-
Algorithm: Implement the OT transform function for insert-insert and delete-insert cases. Prove that TP1 and TP2 hold for your implementation.
-
Scale: If a document has 100 concurrent editors, each making 10 operations/second, the server processes 1000 ops/sec for one document. Estimate the server resources needed.
-
Offline: Design a system for offline editing that syncs changes when the user reconnects. How do you handle conflicts with the online version?
-
Comparison: Compare OT and CRDTs for collaborative editing. What are the trade-offs in terms of complexity, server requirements, and undo/redo support?
What to Learn Next
-> Design Google Drive File storage, sync, and conflict resolution.
-> Design Chat System Real-time messaging with WebSocket and presence.
-> Distributed Consensus Raft, Paxos, and consistency in distributed systems.
-> Data Replication Replicating document state across servers.
-> Message Queues Broadcasting operations to collaborators.
-> Design News Feed Real-time updates with WebSocket.