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

Interview prompt

Design a collaborative document platform like Notion or Google Docs with real-time editing, sharing, comments, search, version history, and offline recovery.

• Model document operations as an ordered, durable log and derive snapshots, search indexes, comments, and notifications.
• Use a CRDT or operational-transform protocol for concurrent edits, with reconnect cursors and bounded document history.
• Separate document permissions from cached collaboration presence and ensure revoked users cannot read future updates.
• Explain offline edits, conflict resolution, snapshots, compaction, sharing, export, deletion, and audit history.

Requirements and scale assumptions

• Create folders and documents, edit rich content concurrently, comment, mention collaborators, search, and share by role.
• Stream remote operations, acknowledge client sequence numbers, show presence, and restore from a version or snapshot.
• Support offline edits, export, retention, legal deletion, link revocation, and per-operation audit records.
• Target p95 operation acknowledgement below 150 ms for a connected document and reconcile offline edits on reconnect.
• Scale millions of documents by document and tenant while isolating very large or highly collaborative documents.
• Never lose an accepted operation; deduplicate client sequence numbers and preserve a replayable operation log.
• Degrade to local editing and queued sync when collaboration, search, or notification services are unavailable.
• Support 50 million documents, 1 million daily editors, and up to 1,000 concurrent collaborators on a hot document.
• Partition by tenant and document ID; shard hot operation streams and snapshot large documents separately.
• Retain encrypted operation logs and periodic snapshots while compacting obsolete history under retention policy.

• Document scale: 50M documents — Tenant and document partitioning drives storage, search, and collaboration capacity.
• Edit acknowledgement: p95 <=150ms — Connected edits should feel immediate while remote convergence remains asynchronous.
• Durable boundary: Committed before async — The ordered document operation log and permission state are authoritative; snapshots are derived.
• Async boundary: At-least-once workers — Keep search indexing, snapshot compaction, notifications, exports, and analytics asynchronous.

Key entities

• InteractioninteractionId, actorId, objectId, type, version, occurredAt

  Canonical document management system interaction with an idempotency key and ordering version.

• ConnectionSessionsessionId, userId, deviceId, roomKey, lastHeartbeat, status

  Ephemeral but observable document management system connection registration used for routing and presence.

• FanoutCursorstreamKey, shard, offset, consumerGroup, updatedAt

  Durable progress marker for document management system fan-out and replay.

• DeliveryReceiptinteractionId, recipientId, channel, attempt, status, deliveredAt

  Deduplicated document management system delivery state for reconnects, retries, or acknowledgements.

Data flow

1. 1. Accept and commit the interactionThe document management system gateway authenticates the actor, validates room or object membership, applies rate limits, and conditionally commits the interaction.
2. 2. Publish an ordered eventAn outbox emits the committed document management system transition with an event ID, partition key, sequence, and replay retention.
3. 3. Fan out by partitionConsumers route document management system events to connected recipients, durable inboxes, or notification channels without making the origin write wait for every recipient.
4. 4. Resume and reconcile connectionsClients reconnect with a cursor; the document management system service replays missed events, deduplicates delivery, and exposes stale or degraded state.
5. 5. Measure latency and recoverOperations tracks document management system publish-to-deliver latency, hot partitions, reconnect storms, dropped events, and consumer lag for replay or repair.

Deep dives and trade-offs

• Ordering, idempotency, and hot keysChoose a document management system partition key that preserves required order while distributing high-volume rooms, users, or objects. Use event IDs, inboxes, consumer offsets, and conditional state transitions for at-least-once delivery. Split or isolate hot partitions without changing the client-visible sequence contract.
• Reconnect and replay semanticsIssue resumable document management system cursors with an expiry and a clear snapshot-plus-delta fallback. Bound replay windows and rebuild from durable state when a cursor is too old. Expose version and freshness so a client can distinguish current, catching up, and degraded state.
• Backpressure and presenceKeep connection heartbeats and ephemeral presence separate from durable document management system interactions. Coalesce safe updates, shed low-value work, and protect critical events during reconnect storms. Measure end-to-end delivery, not only broker publish latency.
• Direct fan-out versus pull-based readsUse push for latency-sensitive document management system deltas and pull or replay for reconnect, history, and recovery. A push-only design loses state when clients disconnect and a pull-only design wastes latency and bandwidth.
• Per-recipient queues versus shared streamsUse shared partitioned streams with per-recipient cursors where fan-out is large, and isolate exceptional high-fanout objects. A queue per recipient becomes expensive and hard to inspect at large scale.
• Strong ordering versus availabilityGuarantee ordering only within the scope the product needs, such as a room, object, or conversation. Global ordering introduces a bottleneck and still does not solve duplicate delivery or reconnect recovery.