Google Docs | FineFrontend

System design interview question

Google Docs

Design a collaborative rich-text editor with immediate local edits, convergent synchronization, durable offline work, stable selections, and clear permissions and save states.

Hard45 min interview

About 15 min read

Read any section, at your own pace

A shared document with two collaborator cursors, revision handling, and acknowledged synchronization. — Document operations converge through the collaboration engine; ephemeral presence stays separate from saved content.

The key idea

Local responsiveness, convergent document content, server acceptance, and durable saving are different guarantees. Explain each one explicitly rather than treating a connected socket as proof that work is saved.

Question & requirements

Design a Google Docs-style frontend where several people edit the same rich-text document. Users type and format text, see collaborators, add comments, work through temporary disconnections, and reopen saved content. Explain the editing model, synchronization, offline durability, undo behavior, permissions, and performance. This is an interview design for a similar product, not a claim about Google Docs’ internal implementation.

Clarify

Architecture & document boundaries

Collaborative editor architecture

Architecture

Editor view + toolbar + comments
          ↕ tested editor binding
       Shared document model
       ├─ Local transaction / undo layer
       ├─ IndexedDB persistence + pending updates
       └─ Synchronization provider
                    ↕ authenticated socket
       Document room / collaboration gateway
       ├─ ACL + schema validation
       ├─ Durable updates + snapshots
       └─ Ephemeral presence

Metadata, sharing, history, export → separate HTTP APIs

Keep framework rendering out of each text keystroke. A mature editor manages selection, DOM reconciliation, composition, and transactions. The app wraps it with document loading, permission controls, toolbar state, and comments. The model and binding are the authority for content; copying the whole text into React state after every edit creates a second source of truth and unnecessary rerenders.

The room server validates access and persists accepted updates. A background compactor can produce checkpoints, and export workers use a consistent accepted snapshot. Gateway routing can follow document ID without forcing all documents through one global in-memory store.

CRDT versus OT: make a choice

For this answer, choose a mature CRDT-based shared document engine with a compatible rich-text editor binding. CRDT means conflict-free replicated data type: its operations are designed to converge under supported concurrent edits. A library such as Yjs provides merge behavior and synchronization primitives. This is an explicit design assumption, not a recommendation to write a new CRDT in an interview or a claim that every editor supports the same schema.

Approach	What it buys	What must still be designed
CRDT default	Local edits can be created while disconnected and merged later	Permission checks, document schema, persistence, compacting, and user intent.
Centralized OT alternative	Server orders operations and transforms concurrent edits	Correct transform rules, client rebasing, offline queues, and editor integration.
Last-write-wins HTML	Simple replacement transport	Loses concurrent work; not a suitable default for this requirement.

Convergence is not authorization or perfect intention preservation. Two editors can legitimately format or delete overlapping content and obtain a technically convergent result that surprises one person. Define selection, comment, undo, and rejected-edit behavior. The server remains the admission authority even though accepted content updates merge without requiring arrival order.

Document model & transport contracts

Model	Important fields	Purpose
Document metadata	id, title, owner, schemaVersion, accessVersion	Lookup, access decisions, and compatible decoding.
Shared content	Stable nodes and collaborative text/marks	Rich-text content and concurrent transformations.
Update envelope	documentId, updateId, payload, clientSession	Deduplication, validation, and durable acknowledgment.
Comment	id, relative anchor, author, body, resolved	Threaded discussion with its own permission rules.
Presence	sessionId, display name, relative selection, expiry	Best-effort collaborator view; not authoritative identity.

Illustrative synchronization envelope

TypeScript

type DocumentUpdate = {
  documentId: string;
  updateId: string;
  schemaVersion: number;
  payload: Uint8Array;
};

type DurableAck = {
  updateId: string;
  acceptedCheckpoint: string;
};

type Rejection = {
  updateId: string;
  reason: 'access-revoked' | 'schema-unsupported' | 'too-large';
};

Binary document updates require an agreed transport encoding; ordinary JSON serialization of a typed array is not a reliable binary protocol. The contracts here are illustrative. State vectors or an equivalent library synchronization summary discover missing operations; an app-level acknowledgment separately indicates which local updates crossed the durability boundary.

Editing	Structured paragraphs, headings, lists, marks, and embedded images	Use a document tree and tested editor binding, not one HTML string.
Collaboration	A modest number of simultaneous editors per document	Document-scoped connections and awareness are sufficient initially.
Offline	Previously opened documents can accept local edits	Persist updates and make remote acceptance visible.
Roles	Owner, editor, commenter, viewer	Content mutations and comments need separate permissions.
Excluded initially	Exact print pagination, spreadsheets, full suggest mode	Focus on safe collaborative editing and recovery.

Google Docs

Question & requirements

Editing & save-state flow

Open

Edit locally

Persist

Synchronize

Reconnect

Architecture & document boundaries

Collaborative editor architecture

CRDT versus OT: make a choice

Document model & transport contracts

Illustrative synchronization envelope

Synchronization & offline durability

Revoked permission creates rejected work, not silent success

Stable positions, selection & composition

Undo, history & export

Performance, layout & mobile

Accessibility, permissions & safety

Failures, tests & observability

A 45-minute interview answer

0–6 minutes

6–15 minutes

15–27 minutes

27–37 minutes

37–45 minutes

Sources & further reading

01Question & requirements

02Editing & save-state flow

Open

Edit locally

Persist

Synchronize

Reconnect

03Architecture & document boundaries

Collaborative editor architecture

04CRDT versus OT: make a choice

05Document model & transport contracts

Illustrative synchronization envelope

06Synchronization & offline durability

Revoked permission creates rejected work, not silent success

07Stable positions, selection & composition

08Undo, history & export

09Performance, layout & mobile

10Accessibility, permissions & safety

11Failures, tests & observability

12A 45-minute interview answer

0–6 minutes

6–15 minutes

15–27 minutes

27–37 minutes

37–45 minutes

Sources & further reading

Question & requirements

Editing & save-state flow

Architecture & document boundaries

CRDT versus OT: make a choice

Document model & transport contracts

Synchronization & offline durability

Stable positions, selection & composition

Undo, history & export

Performance, layout & mobile

Accessibility, permissions & safety

Failures, tests & observability

A 45-minute interview answer