# Design Google Docs Mobile: Real-Time Collaborative Document Editing

Source: https://www.techinterview.org/post/3233475045/design-google-docs-mobile-collaboration/
Updated: 2026-07-26 · techinterview.org

"Design Google Docs mobile" is a frontier [mobile system design](/system-design-interview-guides/) question that combines [real-time collaboration](/post/3233460997/system-design-collaborative-editing/), offline editing, and rich text rendering. The interviewer wants to see if you understand operational transformation (OT), CRDTs, and the architectural tradeoffs that let multiple cursors edit the same paragraph simultaneously without conflicts.

## Functional requirements

- Edit a document on mobile (text, images, lists, tables). Focus on how the editor turns touch gestures and soft-keyboard input into edit operations rather than raw string mutations. Interviewers probe how you model mixed content — a table cell that itself holds formatted text — so the document is a tree of typed nodes, not a flat character buffer.

- See other collaborators' cursors in real time. Cursors and selections are ephemeral presence data, not document state, so send them on a separate lightweight channel and never persist them. A cursor is an index into the text, so it has to be rebased whenever a remote insert or delete lands before its position.

- Edit offline; sync when network returns. The client keeps a local queue of operations and applies them optimistically so typing never blocks on the network. Be ready to explain what happens when that queue is large after hours offline and the buffered edits collide with what other people changed in the meantime.

- Conflict resolution that does not lose work. This is the heart of the question: every device must converge to the same state without dropping a keystroke. A concrete case interviewers like — two users type at the same position at the same instant — should yield both insertions in a deterministic order, never an overwrite.

- Comments and suggestions. Anchor these to a range that moves with the text instead of to absolute character offsets, or a comment drifts to the wrong sentence after an edit above it. Suggestions add a second layer: proposed edits that can be accepted or rejected without yet being applied to the base document.

## Architecture

The document is the central entity. Each edit is an "operation" — insert, delete, format. Operations are exchanged between client and server, transformed against concurrent operations, and applied to converge to the same state on all devices.

## Operational Transformation (OT) vs CRDTs

**OT:** Google Docs' historical approach. The server is the single source of truth. Operations are transformed against concurrent operations to maintain consistency. Hard to get right but mature.

**CRDTs:** conflict-free replicated data types. Operations commute mathematically — any merge order yields the same result. Simpler to reason about; libraries like Yjs and Automerge make this tractable. Newer; many real-time collab tools (Notion, [Linear](/companies/linear/)) use CRDTs.

## The mobile-specific problems

### Offline editing

Mobile is offline more often than desktop. The CRDT approach handles this gracefully — local edits are operations queued in the local log. On reconnect, the queue syncs to the server and merges with concurrent operations.

### Cursor synchronization

Each user has a cursor (or selection range). Cursor positions are sent to the server and broadcast to other clients. Cursors must be transformed against incoming operations to stay positioned correctly.

### Bandwidth optimization

Mobile connections are bandwidth-constrained. Operations must be small. Use binary protocols, batching, and compression.

## Storage

Server: persistent log of operations + periodic snapshots. Snapshots accelerate cold opens (replay only ops since last snapshot).

Client: local SQLite with the operation log + a materialized current document. The materialized doc is what the UI renders.

## Rendering

Rich text on mobile is challenging. iOS uses TextKit (or SwiftUI native AttributedString); Android uses Spannable. Both can be slow on long documents — virtualization is essential.

Render only the visible page; load more as the user scrolls.

## Comments and suggestions

Comments are anchored to a document range. The range tracks the underlying text — if text is inserted before, the comment shifts accordingly. CRDTs make this elegant: anchor the comment to a stable identifier within the document tree.

## Frequently Asked Questions

### What if two users edit the same word simultaneously?

OT/CRDT both handle this — operations are transformed or merged. Both edits succeed in some form. The resulting text might be unexpected, but no edits are lost.

### How does Google Docs handle a network drop during typing?

Edits queue locally. On reconnect, they are uploaded as operations. The server transforms them against any concurrent edits and broadcasts the merged result.

### Why is Google Docs faster than other collab tools?

Years of investment in OT, custom binary protocols, and tight integration with Google Cloud. Latency in the 50–100ms range is feasible.