Collaborative Apps

Design a collaborative application (Google Docs, Notion, Google Sheets) with real-time editing.

R - Requirements

Key Questions:

• How many concurrent users? (10, 100, 1000+)
• Conflict resolution? (OT, CRDT)
• Offline support? (yes, sync when online)
• Document types? (text, spreadsheet, presentation)
• Undo/redo? (yes, per-user or global)

Common Answers:

• 10-1000+ concurrent users
• Operational Transform (OT) or CRDT
• Offline support with sync
• Multiple document types
• Per-user undo/redo

A - Architecture

Collaborative Editing Flow:

Collaboration Architecture:

Architecture Decisions:

• Real-time protocol (WebSocket for bidirectional) - Low latency, bidirectional communication
• Conflict resolution (OT or CRDT) - OT for Google Docs, CRDT for simpler cases
• Document model (tree structure, Slate/ProseMirror) - Tree-based for rich content
• Offline-first (queue operations, sync later) - Work offline, sync when online

Relevant Content:

• Collaborative Editing - Real-time collaboration
• WebSocket Management - Connection handling

D - Data Model

Talking Points:

• Real-time collaboration protocols - OT vs CRDT
• Conflict resolution - How to handle simultaneous edits
• State syncing - Keep all clients in sync

State Management:

• Document structure (tree/nodes)
• Operations queue (for offline)
• User presence (cursors, selections)
• Undo/redo stack (per-user)

Relevant Content:

• Undo/Redo Implementation - History management
• State Machines - Document state
• Persistence Strategies - Offline storage

I - Interface

Features:

• Document editor (contentEditable or custom)
• Cursor indicators (other users' cursors)
• Selection highlighting (other users' selections)
• Presence indicators (who's online)
• Toolbar (formatting, collaboration tools)
• Comments/annotations

Accessibility:

• Keyboard navigation
• Screen reader support
• Focus management

Relevant Content:

• Rich Text Editor - Editor patterns
• Keyboard Shortcuts - Editor shortcuts

O - Optimizations

Performance:

• Debounce operations (don't send every keystroke)
• Batch operations (group multiple edits)
• Virtual rendering (for very long documents)
• Lazy load plugins (formatting tools)

Real-Time:

• Throttle updates (don't send on every change)
• Connection resilience (reconnect, queue operations)
• Conflict resolution (OT/CRDT handles conflicts)

Relevant Content:

• Code Splitting - Lazy load plugins
• Connection Resilience - Reconnect logic
• Background Sync - Offline sync

Implementation Checklist

• Document model (tree structure)
• Real-time protocol (WebSocket)
• Conflict resolution (OT or CRDT)
• Cursor indicators (other users)
• Selection highlighting
• Undo/redo (per-user)
• Offline support (queue operations)
• Background sync (when online)
• Presence system (who's online)
• Comments/annotations

Common Pitfalls

❌ Sending every keystroke → Too many messages, poor performance
✅ Debounce operations (100-300ms), batch multiple edits

❌ No conflict resolution → Lost edits, data corruption
✅ Use OT or CRDT for conflict resolution

❌ No offline support → Lost work on disconnect
✅ Queue operations in IndexedDB, sync when online

❌ Poor connection handling → Lost operations
✅ Connection resilience, reconnect logic, operation queue