Design an Online Document Platform

An Online Document Platform enables multiple users to create, edit, and collaborate on documents simultaneously from anywhere in the world. Google Docs, Microsoft Word Online, Notion, Confluence, and Figma Docs are prime examples of systems that have transformed how we work. Designing such a platform goes beyond simple text storage—it requires real‑time synchronization of concurrent edits, conflict resolution, presence awareness, and robust version control, all while serving millions of concurrent users with minimal latency. This article presents a comprehensive architecture for building a collaborative document platform from the ground up.

Step 1: Requirements Clarification

Functional Requirements

• Create, edit, and save documents with rich text (bold, lists, tables, images).
• Real‑time multi‑user editing – multiple users can edit the same document simultaneously and see each other's changes instantly.
• Cursor and presence indicators – show where collaborators are editing and who is online.
• Comments and mentions – collaborate asynchronously by leaving comments and tagging people.
• Sharing and permission management – share documents with view or edit rights via links or direct invitations.
• Version history – browse past versions and restore any previous state.
• Search documents – find documents by title or content.
• Export to standard formats (PDF, DOCX, markdown).
• Offline editing – allow editing without internet, with changes syncing when back online.
• Notifications – alert users when they are mentioned, or when a document is shared.

Non-Functional Requirements

• Low editing latency – < 100 ms from keystroke to update appearance locally; < 200 ms for remote changes to appear.
• High availability – 99.9%+ uptime. Users must be able to read documents even under heavy load.
• Horizontal scalability – scale to millions of concurrent editing sessions.
• Strong durability – document data must never be lost; durable storage with backups.
• Data consistency – edits from multiple users must converge to a consistent state without corruption.
• Fault tolerance – network or server failures should not lose user work or disconnect sessions permanently.
• Security – encryption in transit and at rest, fine‑grained access controls, audit trails.
• Multi‑device synchronization – edits on one device must seamlessly appear on others.

Step 2: Capacity Estimation

Assume a platform comparable to Google Docs:

• Total users: 500 million
• Daily active users (DAU): 100 million
• Documents created per day: 10 million
• Concurrent editors at peak: 5 million
• Average document size: 50 KB (text + metadata)
• Edit operations per second (peak): ~1 million operations/sec
• Storage: ~500 TB new document data per day; version history multiplies this.
• Collaboration sessions: up to 50 real‑time collaborators per document; thousands of documents edited simultaneously.

Real‑time collaboration demands an efficient synchronization protocol and a high‑throughput WebSocket layer.

Step 3: API Design

The platform provides REST APIs for document management and WebSocket for real‑time collaboration.

REST APIs

• Create Document
  POST /api/v1/documents – Body: { title, content } → { document_id, revision_id }
• Get Document
  GET /api/v1/documents/{id} – Returns latest revision content.
• Share Document
  POST /api/v1/documents/{id}/share – Body: { email, role }
• Update Permission
  PUT /api/v1/documents/{id}/permissions
• Add Comment
  POST /api/v1/documents/{id}/comments
• Get Version History
  GET /api/v1/documents/{id}/revisions
• Export Document
  GET /api/v1/documents/{id}/export?format=pdf
• Search Documents
  GET /api/v1/search?q={query}&scope=owned

All REST endpoints require authentication (JWT) and enforce authorization based on permissions.

Real‑Time Protocol (over WebSocket)

Clients connect to a WebSocket Gateway to join a document collaboration session. The protocol defines:

• join – Client provides document ID and auth token; server sends current document state and presence info.
• operation – Client sends an edit operation (e.g., insert character at position).
• ack – Server acknowledges the operation and broadcasts to other clients.
• presence – Server broadcasts cursor positions and selections.
• heartbeat – Keeps the connection alive.

Idempotency is achieved by assigning each operation a client‑generated unique sequence number; the server deduplicates.

Step 4: High-Level Architecture

The architecture separates the document storage and real‑time collaboration concerns.

• Document Service – manages CRUD, permissions, version history, and exports.
• Collaboration Service – coordinates editing sessions: authenticates connections, broadcasts operations.
• WebSocket Gateway – terminates persistent WebSocket connections; routes messages to Collab Service.
• Operation Processor – applies incoming edit operations to the document state, transforms concurrent operations, and persists changes.
• Document Storage – stores full document state (latest version) in a document database (e.g., MongoDB, DynamoDB) or as serialized files in object storage.
• Metadata Database – relational DB for users, permissions, revisions, comments.
• Redis Cache – holds active document states for low‑latency edits; stores session data.
• Search Service – Elasticsearch for full‑text search.
• Export Worker – asynchronous PDF/Word export using headless browser or rendering engine.
• CDN – serves exported files and static assets.

Step 5: Document Data Model

Core entities:

• User: user_id, email, display name.
• Document: document_id, owner_id, title, current_revision_id, collaborators[], timestamps.
• Revision: revision_id, document_id, operations[] (or snapshot), created_at, author_id.
• Operation: describes a single edit: type (insert, delete, retain), position, content/value.
• Comment: comment_id, document_id, author_id, text, selection_range, resolved, timestamps.
• Permission: document_id, user_id, role (owner, editor, viewer).

Storage Options:

• Document State: For collaborative editing, the document is often represented as a sequence of operations (event log) or as a linear string with metadata. CRDT libraries like Yjs or Automerge store document state as a CRDT data structure.
• Database: DynamoDB or MongoDB for the operation log, with document_id as partition key and revision_id or timestamp as sort key. Redis for the live editing state.
• Version History: Deltas or complete snapshots. To save storage, many platforms store a full snapshot periodically (e.g., every 100 operations) and store the operations in between.

Step 6: Real-Time Collaboration Architecture

The core collaborative editing flow:

1. Join: Client opens WebSocket and sends document ID + token. The server loads the latest document snapshot from the store (or cache), applies any recent operations not yet in the snapshot, and sends the full document state to the client. It also broadcasts presence info (online collaborators).

2. Edit: When Alice types, the client locally applies the change optimistically for instant feedback and sends an operation to the server via WebSocket. The server’s Operation Processor applies the operation, transforms it if necessary (see Step 7), appends it to the operation log, and broadcasts the transformed operation to all other clients (Bob). Bob’s client applies it.

3. Persistence: The operation log is persisted in the document store (e.g., DynamoDB) and periodically compacted into a snapshot to speed up future loading. The snapshot and log are also cached in Redis for active documents.

Step 7: Conflict Resolution

Concurrent edits by multiple users must resolve to a consistent document state. Two dominant algorithms exist:

Operational Transformation (OT)

• How it works: Each operation is transformed against concurrently executed operations to maintain consistency. A central server typically serializes operations (gives them a global order), and transforms incoming operations to account for operations that were applied while the operation was in flight.
• Pros: Proven (Google Docs uses OT), relatively simple when centralized.
• Cons: Complex to implement correctly; transformation functions must be written for each operation type. Central server becomes a bottleneck.

Conflict‑free Replicated Data Types (CRDT)

• How it works: Data structures that mathematically guarantee convergence without transformation. E.g., Yjs uses a CRDT for text that assigns a unique ID to each character and orders them using Lamport timestamps. Operations can be applied in any order, and the state converges.
• Pros: Decentralized; clients can apply operations immediately and sync later (offline‑first). No central transformation server required (or simpler server).
• Cons: Metadata overhead per character; operations history grows unbounded (mitigated by garbage collection). Slightly different editing behavior (e.g., insert at same position is resolved deterministically).

Comparison:

Feature	OT	CRDT
Centralization	Typically requires central server for ordering	Can work peer‑to‑peer; server optional
Offline support	More challenging	Naturally offline‑first
Complexity	High for full document model	Moderate; library usage is straightforward
Performance	Lightweight operations	Heavier metadata per character
Adoption	Google Docs, Etherpad	Yjs (used in many modern apps), Automerge

Modern collaborative platforms increasingly adopt CRDT for their flexibility with offline editing and simpler server logic. With a CRDT, the server acts as a relay and persists operations; the CRDT library on server and client ensures convergence. We'll assume a CRDT‑based approach for this design.

Step 8: Document Synchronization and Offline Support

With CRDT, offline editing becomes straightforward:

• The client maintains a local CRDT document state. When offline, edits are accumulated as operations.
• When back online, the client sends its unacknowledged operations to the server. The server merges them (as CRDT operations commute, no conflicts) and broadcasts to other clients.
• The server can also send any operations that occurred while the client was offline; the client merges them.
• To reduce data transfer, the client can send a local state vector (summarizing received operations) and the server sends only the missing operations.

This model provides seamless offline editing and fast sync.

Step 9: Version History

Version history is implemented by periodically creating named revisions and storing the full document state at that point, while retaining the operation log for granular history.

• Every time a user explicitly saves (or auto‑save after a threshold), a revision is created. The revision stores a snapshot (serialized CRDT state) plus the end operation sequence number.
• The operation log between revisions is retained for fine‑grained playback. Old logs can be compacted or moved to cold storage.
• A user can browse revisions via GET /revisions. To restore, the server loads the snapshot and optionally replays specific operations to reach the desired state, then creates a new revision with the restored content.

Step 10: Permissions and Sharing

• Document ownership: The creator is the owner. Owner can transfer ownership.
• Roles: owner, editor, viewer, commenter. Permissions are stored in a permission table.
• Sharing: Generates a shareable link; anyone with the link can be given view/edit access. Links can be password‑protected, expire, or be restricted to specific domains.
• Enforcement: On REST API calls, the document service checks the permission table (cached). On WebSocket join, the collaboration service verifies that the user has at least viewer access.

Step 11: Search Architecture

Search provides fast document discovery.

• Indexing: When a document is saved (or periodically), its text content (extracted from CRDT state) and metadata are indexed in Elasticsearch. A queue‑based indexer ensures asynchronous processing.
• Permission‑aware search: Search results must only show documents the user has access to. This can be done by indexing permission lists alongside each document and filtering during query, or by post‑filtering results.
• Ranking: Results ranked by relevance (TF‑IDF/BM25), recency, and user interactions.

Step 12: Scalability Strategies

• Stateless microservices: Document Service, Collaboration Service, and Gateway are stateless and horizontally scaled.
• WebSocket scaling: WebSocket connections are persistent. A layer‑4 load balancer distributes connections evenly. A pub‑sub system (Redis Pub/Sub or a message broker) routes messages to the correct collaboration server for a given document.
• Session management: Collaboration sessions for a document are pinned to a specific node or use a distributed in‑memory cache (Redis) for document state.
• Document sharding: The operation log is sharded by document_id. This ensures that all operations for a document reside in the same database shard, supporting fast retrieval.
• Cache: Active documents (latest CRDT state, operations buffer) are kept in Redis. On cache miss, load from durable store. Write‑through or write‑behind strategy ensures durability.
• Multi‑region: Deploy in multiple regions; documents owned by users in a region are served locally. Cross‑region replication of the durable log enables access from other regions with acceptable latency for collaboration (e.g., optimistic local edits synced asynchronously).

Step 13: Reliability and Fault Tolerance

• Connection drops: Client WebSocket auto‑reconnects with exponential backoff. On reconnect, the client sends its state vector to receive missed operations. The server replays them.
• Message retry: Unacknowledged operations are queued locally and retried. Server deduplication prevents double application.
• Data replication: Operation log and snapshots stored in a database with automatic replication (DynamoDB multi‑AZ, MongoDB replica set). Object storage for exports is inherently durable.
• Backup: Periodic snapshots of metadata and the operation log to cold storage.
• Disaster recovery: The entire stack can be recreated from backups in another region.
• Graceful degradation: If the Collaboration Service is overloaded, clients can still edit locally (CRDT) and sync later. Read‑only document access remains available through REST API.

Step 14: Security

• Authentication: OAuth 2.0 / OIDC for user login. Service‑to‑service mTLS.
• Authorization: RBAC for document access. Signed URLs for media.
• Encryption: TLS 1.3 for all connections. Data at rest encrypted (AES‑256). Client‑side encryption of sensitive fields optional.
• Audit logging: All access, sharing, and permission changes logged immutably.
• Secure sharing: Links with random tokens, optional expiration, password, and domain restrictions.
• Input validation: Rich text sanitization to prevent XSS.

Real-World Example: Google Docs‑like Platform

Let's walk through Alice and Bob co‑editing a document.

1. Both join and receive the document state.
2. Alice types 'H'; the operation is assigned a global sequence number (by the server) and broadcast to Bob.
3. Bob simultaneously types 'i'. Both operations integrate via CRDT, resulting in "Hi" at the expected position. No conflicts.
4. The operation log is persisted in cache and database.

Trade-offs

• OT vs. CRDT: OT provides lightweight operations but central server dependency. CRDT enables offline‑first and peer‑to‑peer but has metadata overhead. Modern platforms gravitate to CRDT for its simplicity and offline support.
• Strong consistency vs. latency: A central ordering server (OT) guarantees strong consistency but adds latency. CRDT allows immediate local edits and eventual convergence.
• Snapshot storage vs. operation log: Retaining only snapshots loses fine‑grained history but saves space. Keeping the full operation log enables detailed version history but requires more storage and compaction.
• Centralized server vs. peer‑to‑peer: A central server simplifies authorization and persistence but is a bottleneck and single point. Peer‑to‑peer (WebRTC data channels) reduces server load but complicates persistence and permissions.
• Rich editing features vs. complexity: Supporting tables, images, and embedded content increases operational complexity for both OT and CRDT. Start with plain text and incrementally add features.

Common Mistakes

• Saving the entire document after every keystroke – Wastes bandwidth and CPU. Use deltas/operations.
• Ignoring concurrent edits – Without a proper concurrency control, users will overwrite each other's changes.
• No offline support – Users expect to work on planes; a sync model without local persistence frustrates them.
• Weak permission design – Overly permissive sharing or no access control leads to data leaks.
• Missing version history – Crucial for user trust and recovery.
• Poor WebSocket scaling – A single server cannot hold millions of persistent connections. Use load balancers and distributed session management.
• No conflict resolution strategy – Hoping for no conflicts isn't a strategy; you must design for concurrent edits from day one.

Interview Perspective

System design interviews often feature this question to test your real‑time and distributed state management skills. Expect:

• Design Google Docs.
• How does real‑time collaboration work?
• OT vs. CRDT – explain and compare.
• How do you handle concurrent edits?
• How do you scale WebSocket connections?
• How do you store document versions and support rollback?
• How do you support offline editing?
• How do you guarantee consistency?

Demonstrate understanding of both OT and CRDT, the WebSocket layer, and the trade‑offs between them. Emphasize the importance of an operation log and caching for low‑latency editing.

Summary

An online document platform seamlessly blends real‑time collaboration, robust conflict resolution, and scalable cloud infrastructure. By representing documents as sequences of operations and using CRDTs for convergence, multiple users can edit together with minimal latency and natural offline support. The architecture separates the document management API from the real‑time WebSocket layer, with Redis caching active sessions and a durable store for the operation log. Version history, granular permissions, search, and exports round out the platform. Careful engineering of the synchronization protocol and state management makes a Google Docs‑caliber experience possible for millions of concurrent users.

Further Reading

• Design a Cloud Drive
• Design a Content Management System
• Design a Notification System
• Design a Distributed Cache
• Design a Message Queue
• CQRS Pattern Explained
• Event-Driven Architecture
• Distributed Systems Fundamentals
• Scalability Explained
• Consistency Models Explained