Create a Document Management System like Wikipedia, Notion or Google Docs — System Design Interview Practice

Interview prompt

Design a collaborative document platform where many users can edit rich documents together, recover from disconnects, search content, and safely restore earlier versions.

• Separate the low-latency collaboration path from snapshots, search, notifications, and other asynchronous work.
• Choose and explain an OT or CRDT conflict strategy, including ordering, deduplication, reconnect, and offline edits.
• Model document ownership, folder hierarchy, sharing, and permission revocation as first-class behavior.
• Define how the system stores an operation history, materialized snapshots, immutable versions, and large attachments.

Requirements and scale assumptions

• Create, edit, archive, and delete rich-text or markdown documents.
• Support multiple users editing the same document in real time with cursor and presence indicators.
• Keep version history and allow an authorized user to restore a previous revision without losing auditability.
• Organize documents in workspaces and nested folders with move and rename operations.
• Share documents with users, groups, or links and enforce viewer, commenter, and editor permissions.
• Search document titles and content while restricting results to documents the requester can access.
• Upload and retrieve large attachments without routing their bytes through the collaboration service.
• Acknowledge an accepted edit within 150 ms at p95 for an active session in the same region.
• Deliver an accepted edit to other active collaborators within 250 ms at p95 under normal load.
• Never lose an acknowledged operation; reconnecting clients must be able to resume from a known sequence.
• Keep document opens below 300 ms at p95 for warm snapshots and make search eventually consistent.
• Target 99.9% monthly availability for document reads and collaboration sessions, with graceful reconnect behavior.
• Apply authorization on every document read, edit, share, export, and attachment access—not only at connection time.
• 10 million registered users, 1 million daily active users, and 100,000 peak concurrent editing sessions.
• 50 million documents with an average current text state of 30 KB; attachments are stored separately and can be much larger.
• About 50 million document opens per day and 20 million edit operations per day, with a 10x peak-over-average factor for hot workspaces.
• An active document has three editors on average; a small number of shared documents can attract thousands of viewers.
• The service is multi-region for reads and sessions, while each document has a single ordering authority at a time.

• Peak edit rate: ~2.3K ops/s — 20 million daily operations average to about 230 ops/s; a 10x burst drives the collaboration tier and queue sizing.
• Peak document opens: ~5.8K req/s — 50 million opens per day average to about 580 req/s; cache and read replicas absorb workspace bursts.
• Concurrent connections: 100K sessions — Long-lived WebSocket connections are tracked independently from request-per-second capacity.
• Current text state: ~1.5 TB — 50 million documents times 30 KB of current content, before indexes, replicas, versions, and attachments.

Key entities

• DocumentdocumentId, workspaceId, headVersion, title, aclVersion, deletedAt

  Document identity, current head, and access-policy reference.

• OperationopId, documentId, actorId, baseVersion, operation, lamport, createdAt

  Append-only edit operation used for convergence and audit.

• SnapshotdocumentId, version, blobUri, contentHash, createdAt

  Compacted document state that bounds reconnect and replay cost.

• DocumentMembershipdocumentId, principalId, role, status, updatedAt

  Versioned access membership for read and edit authorization.

Data flow

1. 1. Open a documentThe gateway checks workspace membership and returns the latest snapshot plus a cursor for subsequent operations.
2. 2. Append concurrent editsClients send operations against a known version; the collaboration service orders or transforms them and appends accepted operations.
3. 3. Broadcast changesChange events update connected sessions and caches; reconnecting clients use cursors and never rely on live delivery as the source of truth.
4. 4. Compact and index versionsSnapshot workers periodically materialize the head, retain operation history by policy, and update search indexes from committed versions.
5. 5. Recover conflicts and deletesThe service resolves stale clients, ACL revocations, and restore requests through versioned operations and an auditable tombstone.

Deep dives and trade-offs

• Convergence and operation orderingFor the collaborative document platform, all accepted edits must converge to one versioned head without losing authorship or access policy. Design for the failure case where offline edits, reconnect storms, hot documents, and permission revocation must be recoverable; keep retries, versions, and repair state explicit. Expose freshness, version, lineage, or audit metadata so operators and clients can distinguish current, pending, and degraded state.
• Snapshots, reconnects, and hot documentsFor the collaborative document platform, all accepted edits must converge to one versioned head without losing authorship or access policy. Keep this concern off unrelated request paths and partition it by the collaborative document platform access key. Expose freshness, version, lineage, or audit metadata so operators and clients can distinguish current, pending, and degraded state.
• ACLs, history, and safe restoreFor the collaborative document platform, all accepted edits must converge to one versioned head without losing authorship or access policy. Keep this concern off unrelated request paths and partition it by the collaborative document platform access key. Expose freshness, version, lineage, or audit metadata so operators and clients can distinguish current, pending, and degraded state.
• OT versus CRDTChoose one convergence model and make operation identity, ordering, and compaction explicit; use CRDTs when offline multi-writer behavior dominates. Mixing models or hiding conflict semantics makes restores and audits unpredictable.
• Full operation history versus snapshotsKeep an append log for audit and replay, with periodic snapshots to bound sync and storage cost. Only storing snapshots loses fine-grained recovery; never compacting makes reconnects expensive.
• Live broadcast versus pull syncBroadcast changes for responsiveness but make cursor-based pull the correctness and recovery path. Treating WebSocket delivery as guaranteed loses edits during disconnects.