System Design Guide

architectcritical Relevance15 min read

Design Google Docs Collaborative Editor

Architecting a real-time multiplayer rich-text editor supporting operational sync, peer cursors, and local offline editing cache.

Architecture Focus:

Operational Transformation (OT)CRDT Conflict ResolutionTyping Latency Optimization

1. Problem Statement

Design a collaborative rich-text editor that synchronizes keystrokes in real-time, handles editing conflicts without data loss, and displays peer cursor paths.

2. Business Context & User Friction

Typing experience requires zero lag. An input delay of >50ms or a mismatch in peer updates directly leads to user frustration.

3. Requirements Matrix

Functional Requirements

Provide real-time rich-text formatting and text editing workspace.
Show active cursors and names of other active users on the document canvas.
Support offline editing modes with background document saves.

Non-Functional Requirements

Performance

Local keystroke typing echo under 16ms (60fps targets).
Multiplayer update merges under 50ms.
Lightweight document AST weight.

Scalability

Support up to 100 concurrent editors on a single document.
Isolate conflict resolution calculations to prevent blocking UI.

Accessibility (a11y)

Announce collaborative edits to screen readers.
Enforce keyboard shortcuts configurations.

Security

Sanitize HTML content parses blocking XSS.
Verify document permission structures.

Reliability & Failover

Store document mutations locally if internet drops.
Automatic conflict rollbacks if sync fails.

Observability

Monitor typing input latency (TTI).
Track document synchronization conflict rates.

4. Core User Flows

Multiplayer editing session

User opens document workspace.
App establishes WebSocket link, downloading active AST snapshot.
User types characters; app updates local view instantly (optimistic).
Keystroke changes (operations) serialize, sync to backend, and merge with peer changes.

5. High-Level Design & Layers

The editor models documents as Abstract Syntax Trees (ASTs), executing local edits instantly and resolving peer edits using OT/CRDT engines inside Web Workers.

Frontend Layers

UI Layer: RichTextEditor Canvas, CollaboratorsCursor overlay.
State/Sync Layer: Web Worker running CRDT engines, WebSocket client.
Storage Layer: IndexedDB document caches.

Major Components

RichTextCanvas: Renders text formats and captures typing inputs elements.
CRDTWorker: Executes operation merges and conflict calculations.

Data Flow Pipelines

1. Keystrokes generate document mutation actions.
2. RichTextCanvas displays edits instantly.
3. CRDTWorker serializes edits into operations.
4. WebSockets push operations to synchronization servers.

6. Component Architecture & State Boundaries

Component	Responsibility	State Owned	Dependencies
EditorDashboard	Manages editor workspaces, active collaborator overlays, and toolbar buttons.	Document AST, user list	RichTextCanvas, CollaboratorsCursor

7. State Management

Local UI State

Selection cursors positions
Toolbar format selections

Server Query Cache State

Users document metadata details
Active editor users list

Global/Shared State

Active document ID info

Real-Time & Sync State

Keystrokes mutation operations stream

8. API Contracts Design

GET/api/v1/docs/:id

Get Document

Purpose: Download document layout snapshot.

Sample Response:

{
  "doc": {
    "id": "d1",
    "content": [
      {
        "type": "p",
        "text": "Hello"
      }
    ]
  }
}

9. Caching Strategy

Browser/HTTP Cache

IndexedDB caches document history.
Service Worker caches editor shell layout assets.

Edge CDN Caching

Edge caching of static toolbars.

Application Cache

Local state caching of active collaborator lists.

Invalidation Policies

Clear local caches on document deletion.

10. System Strategies Checklist

Performance Strategy & Budgets

Execute CRDT merges in Web Workers to prevent thread blocking.
Debounce save actions; stream operations in microtasks.
Render only active viewport paragraphs.

Inclusive Accessibility Design

Provide keyboard shortcuts documentation overlays.
Announce active peer edits changes.

Security Safeguards & Risks

Strip XSS tags from HTML outputs.
Authorize document permissions via session tokens.

Telemetry & Production Observability

Log typing latency metrics.
Track WebSocket drop rates.

Graceful Failure & Resilience

Buffer mutations locally in IndexedDB if network drops.
Show offline warning overlays.

Deployment, Rollout & CDN topologies

CSR client dashboard deployed on CDNs.
WebSocket links routed through proxy gateways.

11. Architectural Decisions & Tradeoffs

Decision: CRDT (Yjs) vs Operational Transformation (OT)

Benefit:

CRDT allows offline peer mergers without server validation gates.

Drawback:

Increases memory weight and metadata footprint inside client stores.

When To Use: When building offline-first collaborative interfaces.

12. Interview Answer Framework

How to structure your defense of this architecture during a 45-minute technical system design session:

1. Opening Pitch

Start by explaining typing latency limits. Contrast OT (server-centric) with CRDT (client-first).

2. Requirement Clarification Queries

Do we need support for complete offline editing?
Should we render cursor selections in real-time?

3. Core High-Level Architecture Block

Propose an AppShell housing RichTextCanvas, a Web Worker CRDT coordinator, and WebSocket channels.

4. Strategic Deep Dive Areas

Detail document model representation (AST).
Explain how the Web Worker prevents main thread lag during heavy peer merges.

5. Summary & Defensive Tradeoffs

Conclude by evaluating local data backups and security sanitization.

13. Common Pitfalls & Extension Questions

Candidate Mistakes to Avoid

Running conflict resolution calculations directly on the main thread, causing typing lags.
Not sanitizing HTML inputs, enabling XSS scripts injection.