📝 Problem Description
Design a real-time collaborative document editing platform like Google Docs. Users should be able to create documents, edit them simultaneously with others, see each other's cursors in real-time, and have automatic conflict resolution. Support version history, comments, sharing with permissions, and offline editing with sync.
👤 Use Cases
1.
User wants to creates a new document so that document is created and ready for editing
2.
User wants to types in a document so that changes appear instantly and are auto-saved
3.
Multiple users wants to edit same document simultaneously so that all changes merge correctly without conflicts
4.
User wants to sees collaborator's cursor so that can see where others are typing in real-time
5.
User wants to shares document with team so that team members can view/edit based on permissions
6.
User wants to views version history so that can see and restore previous versions
7.
User wants to adds comment on text so that comment is visible to collaborators with notifications
8.
User wants to edits offline so that changes sync when back online
9.
User wants to searches across documents so that finds relevant documents by content
✅ Functional Requirements
- •Create, read, update, delete documents
- •Rich text editing (formatting, images, tables, lists)
- •Real-time collaborative editing with multiple users
- •Show collaborator cursors and selections
- •Automatic conflict resolution for concurrent edits
- •Auto-save with version history
- •Share documents with permission levels (owner, editor, commenter, viewer)
- •Comments and suggestions mode
- •Offline editing with sync
- •Full-text search across all documents
- •Organize documents in folders/workspaces
- •Export to PDF, Word, HTML
⚡ Non-Functional Requirements
- •Real-time sync latency < 100ms between collaborators
- •Support 100 concurrent editors per document
- •Handle 50M documents with 100K DAU
- •Auto-save with zero data loss
- •99.99% availability
- •Document load time < 1 second
- •Search results < 500ms
⚠️ Constraints & Assumptions
- •Document size up to 10MB (text + embedded images)
- •Maximum 100 concurrent editors per document
- •Version history kept for 365 days
- •Offline edits queue up to 1000 operations
- •Support for 50+ languages with RTL text
📊 Capacity Estimation
👥 Users
100K DAU, 1M registered users
💾 Storage
50TB (50M docs × 1MB average)
⚡ QPS
Document opens: 10K/sec, Operations: 100K/sec, Searches: 1K/sec
🌐 Bandwidth
100GB/day (document syncs + media)
📐 Assumptions
- • 50M total documents
- • 100K daily active users
- • Average document: 1MB (including images)
- • Average 5 collaborators per document
- • 10 versions per document
- • Peak: 10K concurrent editing sessions
💡 Key Concepts
CRITICAL
Operational Transformation (OT)
Algorithm that transforms operations to resolve conflicts when multiple users edit concurrently. Operations are transformed so they can be applied in any order with the same result.
CRITICAL
CRDTs
Conflict-free Replicated Data Types. Alternative to OT that guarantees eventual consistency without central server. Better for offline-first but higher memory usage.
HIGH
Intention Preservation
Key property of OT - the effect of an operation should be preserved even after transformation. If user inserts "X" at position 5, the intent is to insert after the 5th character.
CRITICAL
Convergence
All clients must reach the same final document state regardless of operation order. This is the fundamental requirement of collaborative editing.
HIGH
Presence
Real-time awareness of who is viewing/editing a document. Includes cursor positions, selections, and online status.
HIGH
Version Snapshots
Periodic full copies of document state. Operations since last snapshot are stored separately. Enables efficient version history without storing every keystroke.
MEDIUM
Sticky Sessions
All editors of a document connect to the same server. Simplifies OT by avoiding distributed coordination. Consistent hashing by doc_id.
💡 Interview Tips
- 💡Start by explaining OT vs CRDT trade-offs - this shows deep understanding
- 💡Draw the WebSocket connection flow early - it's the core of real-time
- 💡Discuss sticky sessions for simpler OT implementation
- 💡Explain how cursor positions are handled (they're just another operation)
- 💡Cover the versioning strategy - snapshots + operation logs
- 💡Mention Redis pub/sub for multi-server coordination
- 💡Discuss offline support as a follow-up (shows awareness of mobile)
- 💡Address security: auth on WebSocket, permission checks on every operation