Loading system design…
Loading system design...
Design a real-time collaborative document editing platform like Google Docs where multiple users simultaneously edit the same document with automatic conflict resolution, rich text formatting, presence indicators (coloured cursors), version history, offline editing, and comments/suggestions — all with < 200ms latency for edit propagation.
| Metric | Value |
|---|---|
| Total documents | 5 billion+ |
| Daily active documents | 100 million |
| Daily active users | 300 million |
| Concurrent editors per document (max) | 100 |
| Edit operations per second (platform-wide) | 10 million |
| Average document size | 50 KB (text + formatting) |
| Operation log entries | 1 trillion+ |
| Session servers | 5,000+ |
| WebSocket connections (concurrent) | 50 million |
| Edit propagation latency | < 200ms |
Real-time collaborative editing: multiple users (up to 100) simultaneously edit the same document; all changes appear on every collaborator's screen within < 200ms; no conflicts, no data loss, edits merge automatically
Conflict resolution: when two users type at the same position simultaneously, the system deterministically resolves conflicts so all clients converge to the same final document state (strong eventual consistency)
Rich text editing: support formatting (bold, italic, underline, headings, font size/colour), lists (ordered/unordered), tables, images, links, comments, and suggestions/tracked changes
Document management: create, rename, delete, duplicate, organise into folders; search documents by title and content; share with specific users or via link (viewer/commenter/editor permissions)
Presence and cursors: show each collaborator's cursor position and text selection in the document in real-time (coloured cursors with names); show who is currently viewing the document
Version history: maintain a full edit history; users can browse previous versions with timestamps and author attribution; restore any previous version; view changes between versions (diff)
Offline editing: users can edit documents while offline; changes queued locally; on reconnection, offline edits merge with server state using the conflict resolution algorithm
Comments and suggestions: add comments anchored to text ranges; reply threads on comments; resolve/reopen comments; suggestion mode (tracked changes) — edits shown as suggestions that the owner can accept/reject
Access control and sharing: granular permissions — owner, editor, commenter, viewer; share with specific Google accounts, groups, or 'anyone with the link'; permission inheritance from folders
Export and import: export documents to PDF, DOCX, HTML, plain text, ODT; import from DOCX, HTML, plain text; preserve formatting during conversion
Non-functional requirements define the system qualities critical to your users. Frame them as 'The system should be able to...' statements. These will guide your deep dives later.
Think about CAP theorem trade-offs, scalability limits, latency targets, durability guarantees, security requirements, fault tolerance, and compliance needs.
Frame NFRs for this specific system. 'Low latency search under 100ms' is far more valuable than just 'low latency'.
Add concrete numbers: 'P99 response time < 500ms', '99.9% availability', '10M DAU'. This drives architectural decisions.
Choose the 3-5 most critical NFRs. Every system should be 'scalable', but what makes THIS system's scaling uniquely challenging?
The complete explanation is included with Career and All Access. Compare it with your approach once you’ve worked through the problem.
Your system-design submission history is available after you sign in.
Sign In