Wenhao HeBlog

Design a Collaborative Document Editing System Liike Google Docs

3 min readWenhao He

Design a Collaborative Document Editing System Liike Google Docs

Designing a collaborative document editing system like Google Docs is a common and challenging system design interview problem. It requires building a platform that allows multiple users to edit the same document in real time with low latency and strong consistency. I’ve selected this as my next system design exercise to deepen my understanding of real-time synchronization, conflict resolution, and distributed architecture. Let’s dive in!

Functional Requirements

Let's start by defining what our collaborative editing system needs to accomplish:

  • CRUD Operations: Users should be able to create, read, update, and delete documents
  • Real-Time Collaboration: Multiple users should be able to concurrently edit the same document
  • Live Updates: Edits should be visible in real time
  • Cursor Awareness: Show other users’ cursors and selections in real time to reduce conflicts

Non-Functional Requirements

Our system must scale efficiently and deliver real-time performance:

  • Millions of Documents: Handle large-scale document storage
  • High Concurrency: Support up to 100 concurrent users per document
  • Low Latency: Ensure updates propagate in under 200ms
  • Eventual Consistency: All replicas should converge to the same final state
  • Average Size: Average document size would be up to 100kb

API Design

We'll define RESTful endpoints for basic document operations and a WebSocket endpoint for real-time collaboration:

Document CRUD Endpoints

POST /api/documents
Request:
{
  "title": "Untitled",
  "content": ""
}
Response:
{
  "documentId": "12345"
}

GET /api/documents/{documentId}
Response:
{
  "documentId": "12345",
  "content": "..."
}

PUT /api/documents/{documentId}
Request:
{
  "content": "updated content"
}
Response: 200 OK

WebSocket Collaboration Endpoint


WS /api/documents/{documentId}/collaborate
Payload:
{
  "userId": "u1",
  "operation": { ... },
  "cursor": { "line": 3, "ch": 15 }
}

High-Level System Architecture

Image 1 for blog post titled 'Design a Collaborative Editing System Like Google Docs'

The client communicates with an API Gateway for all document CRUD operations and establishes a WebSocket connection for real-time collaboration. The Document Service handles persistence, routing data to an object store for raw content and a database for metadata. A CDN accelerates read performance for frequently accessed documents.

Document Synchronization Approaches

To maintain consistency across clients, several approaches can be considered:

  • Send Whole Document: Simple but inefficient for frequent edits.
  • Send Edits Only: More efficient for incremental changes.
  • Operational Transform (OT): Used in early versions of Google Docs. Allows transformation of concurrent operations to ensure consistency.
  • Last Write Wins (LWW): Conflict resolution by timestamp. Simple but can lose data.
  • CRDT (Conflict-Free Replicated Data Types): Enables decentralized real-time collaboration without central coordination.

Database Schema Design

Document
- documentId: string
- title: string
- content: string (or reference to object storage)
- createdAt: timestamp
- updatedAt: timestamp
- ownerId: string

Performance Considerations

  • CDN: Serve read-only documents quickly from edge servers.
  • WebSocket Gateway: Route and broadcast real-time events.
  • Caching: Use Redis for hot document metadata and session state.

I hope this gives you a high-level overview of collaborative document editing system design!

#system design#collaborative editing