Design a Collaborative Editing System like Google Docs

1. Single User Editing

Users can create, open, update, and delete their own documents in the browser.

Let's start with the simplest case: one user creates a document and expects it to still exist after a refresh. That means we need a stable document identity and durable storage.

Decision 1: How do we generate document IDs?

Our Choice: Use opaque, globally unique document IDs. This keeps URLs short, supports sharing, and prevents easy enumeration.

Decision 2: Where do we store metadata vs content?

Our Choice: Split metadata and content. The access patterns are different, and the split keeps each store doing what it's good at.

The architecture at this stage: the client calls the Document Service, which writes metadata to a relational database and stores the document body in object storage. We now have a durable single-user editor and a base we can extend for collaboration.

2. Live Edit Streaming

Edits made by one user appear to other collaborators in near real time.

So far we can store documents, but collaboration needs something new: a live channel that streams edits as they happen. If we only poll every few seconds, the editor feels laggy and we waste requests when nothing changes.

Decision 1: How do we push edits in real time?

Our Choice: Use WebSockets for bidirectional streaming.

Decision 2: How do we fan out edits across many gateways?

Our Choice: Use pub/sub fanout. Direct broadcast is fine at small scale, but pub/sub is the safer default once we run many gateway instances. (For a deeper dive, see Message Queue and System Design Template.)

How the flow works:

1. Clients open a WebSocket to the Real-time Gateway.
2. The gateway forwards each edit to the service layer for validation and persistence.
3. After persistence, the service publishes the update to a message queue.
4. The message queue fans out the update to every gateway subscribed to that document.
5. Each gateway broadcasts the update to its connected collaborators.

The architecture at this stage: clients connect to the Real-time Gateway via WebSocket. Edits flow through the Document Service to storage, then fan out through a message queue back to all gateways. This adds real-time streaming without changing the underlying storage model.

3. Concurrent Edit Convergence

Simultaneous edits from different users should converge to the same final document state.

Live streaming is not enough. If two users edit the same sentence at the same time, each client can end up with a different result. We need convergence (all replicas reach the same final state), not just fast delivery.

Decision: How do we resolve concurrent edits?

Our Choice: Use a server-ordered OT-style pipeline. We already have a Collaboration Service in the middle of the edit flow, so a single ordering point keeps client logic simpler and gives us predictable convergence. (We'll compare OT vs CRDTs in the deep dive.)

How the flow works:

1. Clients send edit operations to the Real-time Gateway.
2. The gateway forwards them to the Collaboration Service.
3. The Sequencer (per-document ordering component) transforms concurrent operations and appends the result to the Operation Log (append-only record of edits).
4. The Collaboration Service updates the Document Service with the new state.
5. The transformed operation is published to the message queue.
6. The message queue fans out the update to all gateways, which broadcast to collaborators.

The architecture at this stage: the Real-time Gateway forwards edits to the Collaboration Service, which sequences and transforms them, stores them in the Operation Log, updates the document, and broadcasts consistent results to all clients.

4. Cursor & Selection Presence

Users should see collaborators' live cursors and text selections.

So far we are syncing content, but collaboration feels incomplete without presence. Cursor updates are frequent and short-lived, so we should treat them differently from durable edits.

Decision: Where should cursor data live?

Our Choice: Use an in-memory presence store with TTL-based cleanup. Presence is best-effort, so we prioritize low latency over durability.

How the flow works:

1. The client sends presence_update events over the real-time channel.
2. The Real-time Gateway forwards them to a Presence Service.
3. The Presence Service updates the in-memory store and broadcasts the latest cursor state to other collaborators.
4. Throttling and coalescing prevent overload, and TTL cleans up stale cursors.

The architecture at this stage: a Presence Service and in-memory presence store handle ephemeral cursor updates, while the core edit pipeline remains unchanged.

5. Sharing & Permissions

Users can share documents with others and control access levels.

Collaboration only works if access is controlled. Every read and write must check permissions, and those checks need to stay fast even as sharing grows.

Decision: Where do we keep permission data?

Our Choice: Use a dedicated Access Control Service with its own permission store. We get fast, consistent checks without bloating document metadata.

How the flow works:

1. The Collaboration Service checks permissions before accepting edits.
2. The Document Service checks permissions before returning content.
3. Both services query the Access Control Service, which looks up roles in the Permission Store. Share links map to permission records with a role and optional expiry.

The architecture at this stage: we add an Access Control Service and Permission Store to enforce roles consistently across read and write paths.

6. Version History

Users can view previous revisions and restore a document to an earlier version.

After collaboration, users often need to recover from mistakes. Version history provides safety by letting them inspect and restore prior revisions.

Decision: How do we store revisions efficiently?

Our Choice: Use a hybrid approach. Periodic snapshots go to object storage, while deltas are appended to the operation log.

How the flow works:

1. Users request revision history through the Document Service.
2. The Document Service queries the Revision Store for revision metadata.
3. The Snapshot Writer periodically reads from the Operation Log.
4. It writes a revision record to the Revision Store.
5. It stores the compacted snapshot blob in Object Storage.

Restoring a version updates the head_revision_id pointer and creates a new revision entry.

The architecture at this stage: the Collaboration Service continues to append operations, while the Revision Store and Snapshot Writer provide durable history and fast restores.

The decision depends on where you want complexity and what your product prioritizes. Let's reason from the requirements we already have:

• We already run a collaboration service in the middle of every edit.
• We want clients to stay lightweight.
• Offline-first is not a core requirement in our scope.

Our Choice: With a centralized collaboration service and online-first workflow, OT fits better. It keeps client logic lighter and uses the ordering point we already operate. If offline-first becomes a primary requirement, CRDTs become more attractive despite their complexity.