Design Google Docs

Problem Statement

Design a collaborative document editing service similar to Google Docs where multiple users can create, edit, and share documents in real-time with concurrent editing capabilities. Users see each other's cursors, changes merge automatically, and access is controlled through sharing and permissions.

The core challenge lies in real-time updates, high-contention writes, conflict resolution using Operational Transformation or CRDTs, stateful WebSocket connection management, storage and versioning, and search with permissions. You need to make pragmatic trade-offs under latency, consistency, and scalability constraints, especially for "hot" documents with many concurrent editors. Expect to clarify scope, define core SLAs for latency, availability, and durability, then drill into collaboration algorithms, transport, sharding, and indexing while keeping security and cost in check.

Key Requirements

Functional

• Real-time collaborative editing -- multiple users can edit the same document simultaneously, seeing updates in real time with sub-200ms propagation under normal conditions
• Permissions and sharing -- users can share documents with view, comment, or edit permissions and manage access through links or direct invitations
• Version history -- the system maintains a complete edit history so users can browse past versions, compare changes, and restore to any previous state
• Search with access control -- users can search across their documents by title and content while respecting permissions at query time

Non-Functional

• Scalability -- support millions of daily active users across tens of millions of documents, with up to hundreds of concurrent editors on popular documents
• Reliability -- 99.9 percent uptime with zero data loss during server failures or network partitions
• Latency -- sub-200ms edit propagation to all active collaborators; p99 under 500ms for geographically distributed users
• Consistency -- eventual consistency with causal ordering guarantees, ensuring all clients converge to an identical document state within seconds

What Interviewers Focus On

Based on real interview experiences, these are the areas interviewers probe most deeply:

1. Operational Transformation and Conflict Resolution

This is the heart of any collaborative editor. Interviewers want to see that you can explain how concurrent edits are merged deterministically without losing intent or creating divergent states. Simply naming OT or CRDT is not sufficient -- you need to walk through how operations are represented, transformed, and applied.

Hints to consider:

• Consider how you will represent text operations (insert at position N, delete M characters starting at position P) and what happens when two users insert text at the same position simultaneously
• Discuss whether you will use a centralized server that orders all operations or a peer-to-peer CRDT approach, and justify the trade-offs
• Think about how you will handle the transform function complexity -- do you need to transform against multiple concurrent operations or just against a single acknowledged state
• Address how cursor positions and selections stay correct as the document changes underneath them

2. Real-Time Communication Architecture

Collaborative editing requires bidirectional, low-latency communication channels. Interviewers expect you to design a scalable WebSocket infrastructure that handles connection management, message routing, and failover gracefully.

Hints to consider:

• Explain how you will assign users editing the same file to connection servers and handle horizontal scaling when a single file has dozens of editors
• Discuss how you will detect and handle disconnections, including buffering operations during brief network hiccups versus marking clients as offline
• Consider pub-sub patterns for broadcasting changes and how you will shard or route messages efficiently to avoid broadcasting every operation to every server
• Think about how presence information (who is online, cursor positions) is tracked and distributed separately from document operations to reduce message volume

3. Storage Strategy for Documents and Operation Logs

Documents have unusual access patterns: frequent small updates during editing, occasional full reads on open, and historical queries for version browsing. Your storage layer must optimize for all three.

Hints to consider:

• Store the append-only operation log in a durable database partitioned by document ID, providing a complete audit trail and crash recovery source
• Create periodic snapshots (every 100 operations or every 5 minutes) so document loading does not require replaying the entire operation history from the beginning
• Use a separate blob storage service for embedded media (images, attachments) with content-addressed URLs, keeping the operation log lightweight
• Partition operation logs by time ranges within each document for efficient historical queries

4. Permission Model and Search Integration

Code and document repositories often have complex sharing needs. Interviewers probe how you enforce permissions during search and real-time collaboration.

Hints to consider:

• Explain how you will model permissions (role-based, attribute-based, or ACLs) and where you will enforce them (API gateway, collaboration server, storage layer)
• Consider how permission changes propagate to active editing sessions -- do you kick users out immediately or let them finish current edits
• Think about how search and document browsing respect permissions without requiring expensive per-document checks
• Discuss indexing document content in Elasticsearch with ACL metadata and enforcing authorization at query time to prevent data exposure

Suggested Approach

Step 1: Clarify Requirements

Start by confirming scope and priorities. Ask about the types of content the editor must support (plain text, rich formatting, embedded objects) and expected document sizes. Clarify maximum concurrent collaborators per document and geographic distribution of users. Determine whether offline editing is a hard requirement or a future enhancement. Confirm how far back version history must extend and whether the system needs full-text search across documents.

Step 2: High-Level Architecture

Sketch the core components: an API Gateway for authentication, authorization, and WebSocket upgrade handling; a Collaboration Service cluster where each instance manages active editing sessions for a subset of documents; a Document Store (PostgreSQL) for persisted document metadata, snapshots, and permissions; an Operation Log Store for the append-only sequence of edits per document; a Presence Service that tracks online users and cursor positions; and a Search Index (Elasticsearch) for full-text document search with ACL filtering.

Show the data flow for a user edit: the client sends an operation via WebSocket to the collaboration server, which validates and transforms the operation against any concurrent operations, assigns a sequence number, broadcasts the transformed operation to all connected clients, appends to the operation log, and asynchronously updates the document snapshot in storage.

Step 3: Deep Dive on Conflict Resolution

Walk through the OT algorithm with a concrete example. User A inserts "hello" at position 10 while User B simultaneously deletes 3 characters starting at position 5. Both operations arrive at the server. The server processes them in arrival order: applies User A's insert, then transforms User B's delete against it. Since User A's insert shifted text after position 10, and User B's delete is at position 5 (before the insert), User B's operation does not need adjustment. If the positions overlapped, the transform function would adjust offsets to preserve both users' intent.

The collaboration server assigns monotonically increasing sequence numbers. Each client tracks the last sequence number it has seen. When a client sends an operation, it includes the sequence number of the last server operation it acknowledged. The server transforms the incoming operation against all operations applied since that sequence number. Cursor positions are treated as lightweight operations transformed alongside document edits.

Step 4: Address Secondary Concerns

Cover WebSocket failures and reconnections: clients maintain a local operation buffer and track sequence numbers. On reconnection, the client sends its last known sequence number, and the server replays any missed operations. If the gap is too large, the server sends a full snapshot instead.

Discuss the snapshot strategy: every 100 operations, a background job reads the operation log, applies all operations to the last snapshot, and writes a new snapshot. This bounds document load time to replaying at most 100 operations. For version history, users browse snapshots and the operations between them.

Address monitoring: track WebSocket connection counts per server, operation latency distributions, conflict rates, and storage growth. For security, validate permissions at the WebSocket gateway on every connection and re-check periodically during long sessions.

Related Learning

Deepen your understanding of the patterns used in this problem:

• Slack -- shares WebSocket connection management, room-based fan-out, presence tracking, and message ordering patterns directly applicable to collaborative editing
• Message Queues -- the operation log functions as an append-only durable log similar to Kafka, enabling replay, recovery, and snapshot creation
• Caching -- Redis powers cross-server presence coordination and caches active document state for low-latency reads
• Search -- indexing document content with permission-aware filtering for the full-text search requirement