Design Google Drive / Docs
Consistent collaborative file sharing service with real-time delta updates and conflict resolution.
1. System Requirements
- Real-time document editing and multi-user collaborative cursor presence.
- Save document changes incrementally (delta versions).
- Upload files, configure sharing permissions, and search files.
- Strong consistency on cursor and text states.
- Extremely low latency sync updates (< 100ms).
2. Scale & Resource Estimates
Throughput: 10 Million DAU. Average edit event rate = 50 updates/sec per active document.
Storage & RAM: Document metadata: ~5 GB database space. S3 file storage.
3. System API Endpoints
POST /api/v1/docs/edit
Request: { doc_id: "doc-551", version: 10, operations: [ { type: "insert", index: 12, text: "a" } ] }
Response: { status: "ack", version: 11 }4. Database Schema Design
Table: documents (MongoDB / PostgreSQL)
- doc_id (UUID - Primary Key)
- title (VARCHAR)
- content (TEXT - latest state)
- version (INTEGER)
Table: edit_operations_log (PostgreSQL)
- op_id (BIGINT - Primary Key)
- doc_id (UUID - Foreign Key)
- user_id (UUID)
- version (INTEGER)
- patch_data (JSONB)5. Interactive High-Level Architecture
6. Scalability Deep Dive & Bottlenecks
Uses Operational Transformation (OT) or Conflict-free Replicated Data Types (CRDTs) to resolve collaborative edit conflicts. The WebSocket Gateway routes editing actions (insertions/deletions) to the OT Service, which transforms index offsets based on concurrent actions, increments document versions in an transaction database, and broadcasts transformed patches to other connected clients.
7. Production Scaling Strategies
OT Server Partitioning: Partition OT processing by document_id. Each document is assigned to a specific OT worker via consistent hashing. This ensures all edits for a document are processed sequentially on the same node, avoiding distributed OT complexity.
WebSocket Fan-out: When a document has 50+ concurrent editors, the WebSocket gateway fans out transformed patches to all connected clients. Use Redis Pub/Sub for cross-gateway broadcast. Each gateway handles 10K concurrent WebSocket connections.
Version Compaction: Store every edit operation for undo/redo history. Compact old operations into periodic snapshots (every 100 edits). After 30 days, discard individual operations and keep only snapshots. Reduces storage from O(edits) to O(snapshots).
Chunk-Level Sync: Large files are split into chunks. Each chunk has its own version counter. Concurrent edits to different sections don't conflict. Only the modified chunk is synced, reducing network overhead for large documents by 90%.
Multi-Region Replication: Primary OT server per document in the creator's region. Async replication to 2 secondary regions for disaster recovery. If the primary region fails, promote secondary with <30s failover. Users in the secondary region experience ~50ms additional latency.
Offline Mode: Client queues edits locally when offline. On reconnect, client sends the full edit log with last-known server version. OT server rebases local edits against server state. Conflicts in the same character range prompt user resolution.
8. Runnable Production Starter Code
Scaffold