1. Requirements, Functional and Non-Functional

Before diving into algorithms, we must establish the requirements. Google Docs supports over 500 million monthly active users and more than 3 billion documents have been created. The scale is enormous, and the constraints are strict. Below is the complete requirements breakdown that should inform every architectural decision.

Functional Requirements

• Real-time multi-user editing: Multiple users can edit the same document simultaneously, with all changes reflected on every connected client within one second.
• Cursors and presence: Each user sees colored cursors showing where other users are currently editing.
• Comments and suggestions: Users can add inline comments on text ranges and propose changes (track changes) that the document owner can accept or reject.
• Revision history: Every edit is stored as a revision. Users can browse, diff, and restore any previous version.
• Offline editing: Users can edit documents without an internet connection. Changes sync automatically when reconnected.
• Document permissions: Owner, editor, commenter, and viewer roles. Shareable via link or email invitation.
• Export: Export to PDF, DOCX, ODT, EPUB, plain text, and HTML.
• Search and organization: Full-text search across all documents in a user's Drive.

Non-Functional Requirements

// Google Docs Scale Parameters
public static class DocsScale
{
    public const long TotalDocuments = 3_000_000_000L;
    public const long MonthlyActiveUsers = 500_000_000L;
    public const int MaxConcurrentEditorsPerDoc = 100;
    public const int AverageDocSizeBytes = 50_000;
    public const int MaxDocSizeBytes = 1_000_000;
    public const int AverageRevisionsPerDoc = 100;
    public const long TotalRevisions = TotalDocuments * AverageRevisionsPerDoc; // 300B
    public const int DebounceSaveMs = 500;
    public const int MaxOfflineDays = 30;
    public const int FlushIntervalMs = 5000;
    public const int BroadcastBatchMs = 100;
    public const int SnapshotInterval = 50; // full snapshot every 50 revisions
    public const double AvgCompressedRevisionKB = 10.0;

    public static double EstimatedRevisionStoragePB =>
        TotalRevisions * AvgCompressedRevisionKB / 1_000_000_000_000.0;
}

2. High-Level Architecture Overview

The Google Docs system is composed of several major subsystems that work together to deliver real-time collaboration. Understanding the interaction between these components is critical before we dive into each one individually. The diagram below shows the full architecture.

Component Responsibilities

The flow for a typical edit is: the client captures a keystroke, generates a local operation, sends it over WebSocket to the collaboration server, the server transforms it against any concurrent pending operations, applies it to the canonical document state, persists the operation to the log, and broadcasts the transformed operation to all other connected clients. The entire round trip typically completes in under 100 milliseconds for geographically close users.

3. Document Data Model and CRDT Character Model

The foundation of any collaborative editing system is the data model that represents the document. Google Docs uses a piece table internally, which is a sequence of characters where each character carries metadata: its content, a unique identifier, and its relationship to neighboring characters. This model must support three atomic operations: insert, delete, and retain (for cursor movement without modification).

The Piece Table Approach

A piece table divides the document into segments (pieces) that reference either the original text or the added text buffer. Each piece records its start position, length, and which buffer it references. This is memory-efficient because deleted text is never removed from the original buffer — the piece table simply stops referencing those positions. For collaborative editing, each piece also carries a unique ID so that operations can reference specific characters.

// Piece Table Data Model for Collaborative Editing
public class DocumentState
{
    private readonly List<Piece> _pieces = new();
    private readonly SortedDictionary<long, Piece> _indexById = new();
    private long _nextId = 0;

    public class Piece
    {
        public long Id { get; set; }
        public string Source { get; set; } // "original" or "add"
        public int Start { get; set; }
        public int Length { get; set; }
        public long? NextPieceId { get; set; }
        public long? PrevPieceId { get; set; }
    }

    public List<char> GetText()
    {
        var result = new List<char>();
        foreach (var piece in _pieces)
        {
            var buffer = piece.Source == "add" ? _addBuffer : _originalBuffer;
            for (int i = 0; i < piece.Length; i++)
                result.Add(buffer[piece.Start + i]);
        }
        return result;
    }

    public void InsertAt(int position, string text)
    {
        long prevId = FindPieceAtPosition(position, out int offset);
        foreach (char c in text)
        {
            long id = _nextId++;
            var piece = new Piece
            {
                Id = id,
                Source = "add",
                Start = _addBuffer.Length,
                Length = 1,
                PrevPieceId = prevId
            };
            _addBuffer.Append(c);
            _indexById[id] = piece;
            prevId = id;
        }
    }

    private readonly StringBuilder _addBuffer = new();
    private readonly string _originalBuffer = "";
}

Character-Level Unique IDs

Every character in the document must have a globally unique identifier. The ID format is typically {userId}:{clock} where userId identifies the user who inserted the character and clock is a logical clock (monotonically increasing counter per user). This ensures that even if two users insert characters at the same position simultaneously, their insertions can be deterministically ordered. The ordering rule is: characters with lower userId sort first; if userId is equal, the lower clock value sorts first.

4. Operational Transformation — Deep Dive

Operational Transformation (OT) is the algorithm that Google Docs actually uses. It was first described by Ellis and Gibbs in 1989 and refined by many researchers since. The core idea is elegant: when two operations are concurrent (neither causally precedes the other), the server transforms one against the other so that both can be applied in any order and the result is the same. This property is called the convergence property.

The Three Transformation Rules

For a text editor with insert and delete operations, there are exactly six transformation cases. Let us define operation A as the "newer" operation being transformed against operation B which was already applied. The transformation function is transform(A, B) = A' where A' is A adjusted to account for B's effect.

// Operational Transformation Engine — Full Implementation
public class OTEngine
{
    /// Transforms operation A against operation B (B was applied first).
    /// Returns a new operation A' that accounts for B's effect on the document.
    public static Operation Transform(Operation a, Operation b)
    {
        // Case: Insert vs Insert
        if (a.Type == OpType.Insert && b.Type == OpType.Insert)
        {
            if (a.Position > b.Position)
                return new Operation(a.Type, a.Position + b.Length, a.Text, a.UserId);
            if (a.Position == b.Position)
            {
                // Tiebreak by user ID — higher ID goes after
                return a.UserId > b.UserId
                    ? new Operation(a.Type, a.Position + b.Length, a.Text, a.UserId)
                    : a.Clone();
            }
            return a.Clone(); // a.Position < b.Position, no shift
        }

        // Case: Insert vs Delete
        if (a.Type == OpType.Insert && b.Type == OpType.Delete)
        {
            if (a.Position > b.Position)
                return new Operation(a.Type, a.Position - b.Length, a.Text, a.UserId);
            if (a.Position == b.Position)
                return new Operation(a.Type, b.Position, a.Text, a.UserId);
            return a.Clone();
        }

        // Case: Delete vs Insert
        if (a.Type == OpType.Delete && b.Type == OpType.Insert)
        {
            if (a.Position >= b.Position)
                return new Operation(a.Type, a.Position + b.Length, a.Text, a.UserId);
            return a.Clone();
        }

        // Case: Delete vs Delete
        if (a.Type == OpType.Delete && b.Type == OpType.Delete)
        {
            if (a.Position > b.Position)
            {
                int newPos = a.Position - b.Length;
                int newLen = Math.Min(a.Length, Math.Max(0, b.Position - a.Position));
                return new Operation(a.Type, newPos, new string('x', newLen), a.UserId);
            }
            if (a.Position == b.Position)
                return new Operation(OpType.NoOp, 0, "", a.UserId);
            // a.Position < b.Position but overlap check
            if (a.Position + a.Length > b.Position)
            {
                int overlap = Math.Min(a.Length, b.Position - a.Position + b.Length);
                return new Operation(a.Type, a.Position, a.Text.Substring(0, a.Length - overlap), a.UserId);
            }
            return a.Clone();
        }

        return a.Clone();
    }

    /// Transform a client operation against a list of server-applied operations
    public static Operation TransformAgainst(Operation clientOp, List<Operation> serverOps)
    {
        Operation transformed = clientOp;
        foreach (var serverOp in serverOps)
        {
            if (serverOp.UserId != clientOp.UserId)
                transformed = Transform(transformed, serverOp);
        }
        return transformed;
    }
}

The Centralized Server Model

Google Docs uses a centralized server architecture rather than peer-to-peer OT. In this model, the server is the single source of truth. When a client sends an operation, the server holds a lock on the document, transforms the operation against all operations that have been applied since the client's last acknowledged version, applies the transformed operation to the canonical document state, and then broadcasts the result to all other clients. This eliminates the complex multi-way transformation scenarios that plague peer-to-peer OT and makes the system much easier to reason about.

5. CRDTs — The Alternative Approach

Conflict-Free Replicated Data Types (CRDTs) take a fundamentally different approach to collaborative editing. Instead of transforming operations at a central server, CRDTs assign each character a globally unique ID and a fractional position that implicitly defines its order in the document. When two users insert characters at the same position simultaneously, their characters simply occupy different fractional positions (e.g., 0.5 and 0.6) and both appear in the final document in a deterministic order. No transformation is needed. No central server coordination is required for correctness.

How CRDT Positions Work

In a CRDT text editor, each character is assigned a rational number position. When inserting a character between characters at positions 0.33 and 0.34, the new character gets position 0.335. This fractional indexing scheme guarantees that there is always room for new insertions between any two adjacent characters. The position is never reused, so there is never a conflict. Characters are sorted by position to produce the document text.

// CRDT Character Model — Fractional Position Approach
public class CRDTDocument
{
    private readonly SortedDictionary<Fraction, CRDTChar> _characters = new();
    private readonly Fraction START = new Fraction(0, 1);
    private readonly Fraction END = new Fraction(1, 1);

    public class CRDTChar
    {
        public char Character { get; set; }
        public string UserId { get; set; }
        public long Clock { get; set; }
        public Fraction Position { get; set; }
        public bool IsDeleted { get; set; } // tombstone for lazy deletion
    }

    public void Insert(string userId, long clock, Fraction afterPos, char ch)
    {
        Fraction nextPos = GetNextPosition(afterPos);
        var crdtChar = new CRDTChar
        {
            Character = ch,
            UserId = userId,
            Clock = clock,
            Position = nextPos,
            IsDeleted = false
        };
        _characters[nextPos] = crdtChar;
    }

    public void Delete(string userId, long clock, Fraction charPos)
    {
        if (_characters.TryGetValue(charPos, out var crdtChar))
        {
            crdtChar.IsDeleted = true; // tombstone — actual removal later
        }
    }

    private Fraction GetNextPosition(Fraction after)
    {
        // Find the character immediately after `after` in sorted order
        var keys = _characters.Keys.ToList();
        int idx = keys.IndexOf(after);
        Fraction next = idx + 1 < keys.Count ? keys[idx + 1] : END;
        // Return midpoint between after and next
        return Fraction.Midpoint(after, next);
    }

    public string GetText()
    {
        return string.Concat(
            _characters.Values
                .Where(c => !c.IsDeleted)
                .OrderBy(c => c.Position)
                .Select(c => c.Character)
        );
    }
}

// Fraction with arbitrary-precision numerator/denominator
public struct Fraction : IComparable<Fraction>
{
    public long Numerator { get; }
    public long Denominator { get; }

    public Fraction(long n, long d) { Numerator = n; Denominator = d; }

    public static Fraction Midpoint(Fraction a, Fraction b)
    {
        // Simple midpoint: (a + b) / 2 using long arithmetic
        long num = a.Numerator * b.Denominator + b.Numerator * a.Denominator;
        long den = 2 * a.Denominator * b.Denominator;
        return new Fraction(num, den);
    }

    public int CompareTo(Fraction other)
    {
        long lhs = Numerator * other.Denominator;
        long rhs = other.Numerator * Denominator;
        return lhs.CompareTo(rhs);
    }
}

Advantages of CRDTs

• No central coordination: Every client can independently merge operations without a server.
• Always available: The system never rejects operations — it always accepts and merges.
• Simpler offline support: Clients can edit freely and merge on reconnect without server transformation.
• Better for P2P: Natural fit for distributed, multi-device editing without a central authority.

Disadvantages of CRDTs

• Memory overhead: Each character carries a unique ID and fractional position (16+ bytes per character vs. 1 byte for plain text).
• Tombstone accumulation: Deleted characters remain in memory as tombstones until garbage collected.
• Fractional position growth: Positions can grow to require big integers after many insertions between the same neighbors.
• Non-trivial garbage collection: Removing tombstones requires coordination or special protocols.

6. OT vs CRDTs — Comprehensive Comparison

Understanding the trade-offs between OT and CRDTs is essential for any system design interview. Both approaches solve the same fundamental problem — concurrent modification of shared state — but they use different mechanisms and have different trade-offs.

7. Real-Time WebSocket Communication Layer

The real-time communication layer is the nervous system of Google Docs. Every keystroke, cursor movement, and selection change is transmitted over WebSocket connections with minimal latency. The design of this layer directly impacts user experience — too much batching introduces visible lag, too little batching wastes bandwidth and server resources.

Connection Lifecycle

When a user opens a document, the following sequence occurs: the client authenticates with an OAuth token, the load balancer routes the WebSocket connection to a collaboration server instance (with sticky sessions to maintain affinity), the server verifies the token and checks document permissions, the server subscribes the connection to the document's pub-sub channel, the server sends the current document state and any operations in flight that the client may have missed, and finally the client reconciles its local state with the server's authoritative state.

// WebSocket Collaboration Server — Connection Handler
public class CollaborationWebSocketHandler
{
    private readonly ConcurrentDictionary<string, DocumentChannel> _channels = new();
    private readonly IDocumentStore _docStore;
    private readonly IPermissionService _permissions;

    public async Task HandleConnectionAsync(WebSocket socket, string docId, string authToken)
    {
        // Step 1: Authenticate and authorize
        var user = await _permissions.ValidateTokenAsync(authToken);
        var access = await _permissions.GetAccessLevelAsync(user.Id, docId);
        if (access == AccessLevel.None)
        {
            await socket.CloseAsync(WebSocketCloseStatus.PolicyViolation,
                "Access denied", CancellationToken.None);
            return;
        }

        // Step 2: Get or create document channel
        var channel = _channels.GetOrAdd(docId, id => new DocumentChannel(id));
        var clientConn = new ClientConnection(socket, user.Id, access);
        channel.AddClient(clientConn);

        try
        {
            // Step 3: Send current document state
            var docState = await _docStore.GetDocumentStateAsync(docId);
            await clientConn.SendAsync(new StateMessage
            {
                Type = "state",
                Content = docState.Text,
                Version = docState.Version,
                Clients = channel.GetConnectedClients()
            });

            // Step 4: Message loop
            while (socket.State == WebSocketState.Open)
            {
                var raw = await clientConn.ReceiveAsync();
                var msg = JsonSerializer.Deserialize<OperationMessage>(raw);
                await channel.ProcessOperationAsync(clientConn, msg);
            }
        }
        finally
        {
            channel.RemoveClient(clientConn);
            if (channel.ClientCount == 0)
                _channels.TryRemove(docId, out _);
        }
    }
}

Message Protocol

All messages between client and server use a compact JSON protocol. Operation messages are small — typically 50-100 bytes. Cursor and presence updates are even smaller. The server batches outgoing broadcasts every 100 milliseconds or every 50 operations, whichever comes first, to reduce network overhead.

Pub-Sub for Large Document Channels

For documents with 100+ concurrent editors, the collaboration server uses Redis pub-sub to distribute the document channel across multiple server instances. Each server subscribes to the document's Redis channel and forwards operations to locally connected clients. This horizontal scaling approach means a single document can be served by multiple machines without any one machine becoming a bottleneck.

// Redis Pub-Sub for Cross-Server Document Distribution
public class DistributedDocumentChannel
{
    private readonly ISubscriber _redisSub;
    private readonly string _channelName;
    private readonly ConcurrentDictionary<string, ClientConnection> _localClients = new();

    public DistributedDocumentChannel(string docId, IConnectionMultiplexer redis)
    {
        _channelName = $"doc:{docId}";
        _redisSub = redis.GetSubscriber();
        _redisSub.Subscribe(_channelName, async (ch, msg) =>
        {
            var broadcast = JsonSerializer.Deserialize<BroadcastMessage>(msg);
            // Forward to locally connected clients only
            foreach (var client in _localClients.Values)
            {
                if (client.UserId != broadcast.OriginUserId)
                    await client.SendAsync(broadcast);
            }
        });
    }

    public async Task PublishOperationAsync(ClientConnection sender, OperationMessage op)
    {
        // Serialize and publish to Redis channel
        var broadcast = new BroadcastMessage
        {
            Type = "op-broadcast",
            Operation = op,
            OriginUserId = sender.UserId,
            Version = Interlocked.Increment(ref _version)
        };
        await _redisSub.PublishAsync(_channelName,
            JsonSerializer.Serialize(broadcast));
    }
}

8. Server-Side Operation Serialization and Mutex

The most critical invariant in the Google Docs system is that operations on a single document must be applied in a consistent, serialized order. If two operations arrive at the server simultaneously, they must be transformed against each other and applied in a deterministic sequence. Violating this invariant would cause document divergence — different clients seeing different document states — which is catastrophic for a collaborative editor.

Per-Document Mutex

The collaboration server uses a mutex (mutual exclusion lock) per document to serialize operation processing. When an operation arrives for document D, the server acquires the lock for D, transforms the operation against all pending operations in D's operation log, applies the transformed operation to the canonical state, appends it to the operation log, releases the lock, and broadcasts the result. This ensures that no two operations on the same document are ever processed concurrently.

// Per-Document Mutex for Operation Serialization
public class DocumentOperationProcessor
{
    private readonly ConcurrentDictionary<string, SemaphoreSlim> _locks = new();
    private readonly ConcurrentDictionary<string, List<Operation> _pendingOps = new();
    private readonly ConcurrentDictionary<string, DocumentState> _docStates = new();
    private readonly IOperationLog _opLog;

    public async Task<Operation> ProcessOperationAsync(
        string docId, Operation clientOp)
    {
        var docLock = _locks.GetOrAdd(docId,
            _ => new SemaphoreSlim(1, 1));

        await docLock.WaitAsync();
        try
        {
            // Get pending operations since client's last known version
            var pending = _pendingOps.GetOrAdd(docId, _ => new List<Operation>());

            // Transform client operation against all pending operations
            var transformed = clientOp;
            foreach (var pendingOp in pending)
            {
                if (pendingOp.UserId != clientOp.UserId)
                {
                    transformed = OTEngine.Transform(transformed, pendingOp);
                }
            }

            // Apply to canonical document state
            var state = _docStates.GetOrAdd(docId, _ => new DocumentState());
            state.ApplyOperation(transformed);

            // Append to pending ops and operation log
            pending.Add(transformed);
            await _opLog.AppendAsync(docId, transformed);

            return transformed;
        }
        finally
        {
            docLock.Release();
        }
    }

    public List<Operation> GetPendingOpsSinceVersion(
        string docId, int clientVersion)
    {
        if (!_pendingOps.TryGetValue(docId, out var pending))
            return new List<Operation>();
        return pending.Skip(clientVersion).ToList();
    }
}

Why a Mutex and Not a Queue?

A queue-per-document would also work, but a mutex with in-memory operation log is more efficient because the operations are small (50 bytes each) and we only need to hold them for a few seconds before flushing to persistent storage. The mutex allows the server to process operations as fast as they arrive without the overhead of queue management. The operation log in memory is periodically flushed to Redis Streams or Kafka for durability.

9. Auto-Save, Version Vectors, and Revision History

Google Docs auto-saves every change. The save is debounced — if the user is actively typing, the save waits 500 milliseconds after the last keystroke. This prevents excessive writes during rapid typing while ensuring no work is lost. The revision history system stores every version of the document as a compressed delta, with full snapshots taken periodically for efficient recovery.

Version Vector Design

Each client maintains a version vector that tracks how many operations it has seen from each user. The version vector is sent with every operation so the server can determine which operations the client is missing. When the server sends an operation to a client, it includes the version so the client can update its vector.

// Version Vector for Causal Ordering
public class VersionVector
{
    private readonly Dictionary<string, long> _versions = new();

    public void Increment(string userId)
    {
        _versions.TryGetValue(userId, out long current);
        _versions[userId] = current + 1;
    }

    public long GetVersion(string userId)
    {
        _versions.TryGetValue(userId, out long v);
        return v;
    }

    /// Returns true if this vector causally precedes or equals the other
    public bool HappensBefore(VersionVector other)
    {
        foreach (var kvp in _versions)
        {
            if (!other._versions.TryGetValue(kvp.Key, out long otherVer) ||
                kvp.Value > otherVer)
                return false;
        }
        return true;
    }

    /// Returns the operations that `this` is missing compared to `other`
    public List<string> GetMissingUsers(VersionVector other)
    {
        var missing = new List<string>();
        foreach (var kvp in other._versions)
        {
            if (!_versions.TryGetValue(kvp.Key, out long myVer) ||
                myVer < kvp.Value)
                missing.Add(kvp.Key);
        }
        return missing;
    }

    /// Merge two version vectors (take max of each user)
    public VersionVector Merge(VersionVector other)
    {
        var merged = new VersionVector();
        foreach (var kvp in _versions)
            merged._versions[kvp.Key] = kvp.Value;
        foreach (var kvp in other._versions)
        {
            merged._versions.TryGetValue(kvp.Key, out long current);
            merged._versions[kvp.Key] = Math.Max(current, kvp.Value);
        }
        return merged;
    }
}

Revision Storage Strategy

Storing full copies of the document for every revision would be prohibitively expensive. Instead, revisions are stored as compressed deltas — the operations that changed the document from the previous revision. Full snapshots are taken every 50 revisions so that recovering a revision near a snapshot does not require replaying hundreds of operations. The revision storage uses gzip compression, which typically achieves 10:1 compression on operation logs.

// Revision Storage with Snapshots and Compressed Deltas
public class RevisionStorageService
{
    private const int SnapshotInterval = 50;
    private readonly IBlobStorage _blobStore;
    private readonly IDocumentMetadataStore _metaStore;

    public async Task<RevisionInfo> SaveRevisionAsync(
        string docId, List<Operation> operations, int baseRevision)
    {
        int revNumber = baseRevision + 1;
        bool isSnapshot = revNumber % SnapshotInterval == 0;

        byte[] data;
        if (isSnapshot)
        {
            // Full document state as snapshot
            var doc = await GetFullDocumentAsync(docId);
            data = Encoding.UTF8.GetBytes(doc.Text);
        }
        else
        {
            // Delta: serialize operations
            string delta = string.Join("\n",
                operations.Select(o => o.Serialize()));
            data = Encoding.UTF8.GetBytes(delta);
        }

        // Compress with gzip
        byte[] compressed = GzipCompress(data);

        // Store in blob storage (S3 / Cloud Storage)
        string key = $"{docId}/rev-{revNumber}.gz";
        await _blobStore.PutAsync(key, compressed);

        // Update metadata
        var info = new RevisionInfo
        {
            DocumentId = docId,
            RevisionNumber = revNumber,
            IsSnapshot = isSnapshot,
            SizeBytes = compressed.Length,
            CreatedBy = operations.First().UserId,
            CreatedAt = DateTime.UtcNow
        };
        await _metaStore.SaveRevisionInfoAsync(info);

        return info;
    }

    /// Retrieve a specific revision by replaying from nearest snapshot
    public async Task<string> GetRevisionAsync(string docId, int revNumber)
    {
        // Find nearest snapshot
        int snapshotRev = (revNumber / SnapshotInterval) * SnapshotInterval;
        string text;

        if (snapshotRev == 0)
            text = ""; // no snapshot, start from empty
        else
            text = await LoadSnapshotAsync(docId, snapshotRev);

        // Replay deltas from snapshot to target revision
        for (int i = snapshotRev + 1; i <= revNumber; i++)
        {
            var ops = await LoadDeltaAsync(docId, i);
            foreach (var op in ops)
                text = ApplyOperation(text, op);
        }

        return text;
    }

    private byte[] GzipCompress(byte[] data)
    {
        using var output = new MemoryStream();
        using (var gzip = new GZipStream(output, CompressionLevel.Optimal))
            gzip.Write(data, 0, data.Length);
        return output.ToArray();
    }
}

Storage Cost Estimation

10. Offline Editing and Synchronization

Offline editing is one of the most complex features of Google Docs. The system must allow users to make edits without an internet connection, store those edits locally, and seamlessly synchronize them with the server upon reconnection — all while maintaining document consistency with any changes made by other users during the offline period.

Architecture of Offline Support

When a user opens a document while online, the browser caches the full document state and the operation engine in IndexedDB. Service workers intercept network requests and serve the cached document when offline. Local edits are applied immediately using the local OT engine and stored in an operation queue in IndexedDB. The queue is ordered by sequence number and includes all metadata needed for server-side transformation.

// Offline Editing and Sync Engine
public class OfflineSyncEngine
{
    private readonly ILocalOperationQueue _opQueue;
    private readonly IOperationServerClient _serverClient;
    private readonly ILocalDocumentStore _localStore;
    private readonly IDocumentState _localState;

    public event Action<SyncConflict>? OnConflict;
    public event Action? OnSyncComplete;

    public async Task<bool> QueueLocalOperationAsync(Operation op)
    {
        // Apply locally first (instant feedback)
        _localState.ApplyOperation(op);

        // Persist to IndexedDB queue
        await _opQueue.EnqueueAsync(op);

        // Try to send if online
        if (IsOnline())
            await TryFlushQueueAsync();

        return true;
    }

    public async Task TryFlushQueueAsync()
    {
        while (_opQueue.Count > 0)
        {
            var op = _opQueue.Peek();
            try
            {
                var result = await _serverClient.SendOperationAsync(op);
                if (result.Accepted)
                {
                    _opQueue.Dequeue();
                    // Update local version vector
                    _localState.UpdateVersion(result.ServerVersion);
                }
                else if (result.Conflict)
                {
                    // Server could not transform — needs user intervention
                    OnConflict?.Invoke(new SyncConflict
                    {
                        LocalOp = op,
                        ServerOps = result.ConflictingOps,
                        Message = result.ErrorMessage
                    });
                    break;
                }
            }
            catch (HttpRequestException)
            {
                // Still offline — stop flushing
                break;
            }
        }

        if (_opQueue.Count == 0)
            OnSyncComplete?.Invoke();
    }

    public async Task ReconcileWithServerAsync()
    {
        // On reconnection, get server state and missing operations
        var serverState = await _serverClient.GetDocumentStateAsync();
        var missingOps = await _serverClient.GetMissingOpsAsync(
            _localState.VersionVector);

        // Transform queued operations against server operations
        var myQueuedOps = await _opQueue.GetAllAsync();
        var transformedQueue = new List<Operation>();

        foreach (var myOp in myQueuedOps)
        {
            var transformed = myOp;
            foreach (var serverOp in missingOps)
            {
                if (serverOp.UserId != myOp.UserId)
                    transformed = OTEngine.Transform(transformed, serverOp);
            }
            transformedQueue.Add(transformed);
        }

        // Replace local queue with transformed operations
        await _opQueue.ClearAsync();
        foreach (var op in transformedQueue)
            await _opQueue.EnqueueAsync(op);

        // Apply server state to local
        _localState.SetText(serverState.Text);

        // Flush transformed queue
        await TryFlushQueueAsync();
    }

    private bool IsOnline() =>
        navigator.OnLine; // browser API
}

Conflict Resolution Strategies

11. Comments, Suggestions, and Track Changes

Comments and suggestions (track changes) are features layered on top of the core collaborative editing system. They add a metadata layer that references specific text ranges and allows non-destructive proposed changes. This complexity requires a dedicated microservice architecture.

Comments Data Model

Each comment is anchored to a range of characters in the document. The anchor must survive insertions and deletions around it — if a user inserts text before a comment's anchor, the anchor shifts accordingly. Comments support threading (replies), resolution (marking as resolved), and @mentions (notification triggers).

// Comments and Suggestions Data Model
public class Comment
{
    public Guid Id { get; set; } = Guid.NewGuid();
    public Guid DocumentId { get; set; }
    public long AuthorId { get; set; }
    public string AuthorName { get; set; } = "";
    public string Content { get; set; } = "";

    // Character-level anchoring
    public long AnchorStartCharId { get; set; } // references CRDT char ID
    public long AnchorEndCharId { get; set; }
    public int AnchorStartOffset { get; set; } // fallback position
    public int AnchorEndOffset { get; set; }

    public bool IsResolved { get; set; }
    public Guid? ParentCommentId { get; set; } // for threading
    public DateTime CreatedAt { get; set; } = DateTime.UtcNow;
    public List<Mention> Mentions { get; set; } = new();

    public class Mention
    {
        public long UserId { get; set; }
        public string Email { get; set; } = "";
    }
}

public class Suggestion
{
    public Guid Id { get; set; } = Guid.NewGuid();
    public Guid DocumentId { get; set; }
    public long AuthorId { get; set; }
    public Operation ProposedOperation { get; set; } = null!;

    // The suggested text for display in UI
    public string SuggestedText { get; set; } = "";
    public SuggestionStatus Status { get; set; } = SuggestionStatus.Pending;
    public long? AcceptedBy { get; set; }
    public DateTime CreatedAt { get; set; } = DateTime.UtcNow;
    public DateTime? ResolvedAt { get; set; }
}

public enum SuggestionStatus
{
    Pending,
    Accepted,
    Rejected
}

Notification Flow for Comments

When a user adds a comment with an @mention, the following sequence occurs: the comment service persists the comment to PostgreSQL, extracts @mention user IDs from the comment text, looks up their notification preferences, and dispatches notifications through the notification service. Online users receive a real-time WebSocket push. Offline users receive an email notification. The notification service respects user preferences (email frequency, quiet hours) and deduplicates notifications for the same comment thread.

// Comment Notification Dispatcher
public class CommentNotificationService
{
    private readonly INotificationPreferenceStore _prefs;
    private readonly IWebSocketBroadcaster _broadcaster;
    private readonly IEmailService _emailService;

    public async Task OnCommentAddedAsync(Comment comment)
    {
        // Get document collaborators
        var collaborators = await GetDocumentCollaboratorsAsync(
            comment.DocumentId);

        // Check for @mentions
        foreach (var mention in comment.Mentions)
        {
            var userPrefs = await _prefs.GetAsync(mention.UserId);

            // Check if user is currently online
            bool isOnline = await _broadcaster.IsUserOnlineAsync(mention.UserId);

            if (isOnline && userPrefs.WantsRealtimeNotifications)
            {
                // Push via WebSocket
                await _broadcaster.SendToUserAsync(mention.UserId, new
                {
                    type = "comment-mention",
                    commentId = comment.Id,
                    authorName = comment.AuthorName,
                    content = comment.Content,
                    documentId = comment.DocumentId
                });
            }
            else if (userPrefs.WantsEmailNotifications)
            {
                // Queue email
                await _emailService.SendAsync(new EmailMessage
                {
                    To = mention.Email,
                    Subject = $"{comment.AuthorName} mentioned you in a document",
                    Body = BuildEmailBody(comment),
                    Priority = EmailPriority.Normal
                });
            }
        }
    }
}

12. Permission Model and Access Control

Google Docs has a granular permission model with four roles: Owner, Editor, Commenter, and Viewer. Permissions can be granted individually by email address or via a shareable link. The permission system must be checked at multiple points: when a user opens a document, when a user sends an operation, and when a user tries to export or share the document.

Access Control Matrix

// Permission Service Implementation
public class PermissionService
{
    private readonly IPermissionStore _store;
    private readonly ICacheService _cache;

    public async Task<AccessLevel> GetAccessLevelAsync(
        long userId, string documentId)
    {
        string cacheKey = $"perm:{documentId}:{userId}";
        var cached = await _cache.GetAsync<AccessLevel?>(cacheKey);
        if (cached.HasValue) return cached.Value;

        var perm = await _store.FindAsync(userId, documentId);
        var level = perm?.Level ?? AccessLevel.None;

        // Cache for 5 minutes
        await _cache.SetAsync(cacheKey, level, TimeSpan.FromMinutes(5));
        return level;
    }

    public async Task<bool> CanEditAsync(long userId, string documentId)
    {
        var level = await GetAccessLevelAsync(userId, documentId);
        return level == AccessLevel.Owner || level == AccessLevel.Editor;
    }

    public async Task<bool> CanCommentAsync(long userId, string documentId)
    {
        var level = await GetAccessLevelAsync(userId, documentId);
        return level != AccessLevel.None && level != AccessLevel.Viewer;
    }

    public async Task ShareDocumentAsync(
        string documentId, long ownerId, string targetEmail, AccessLevel level)
    {
        // Verify the sharer has owner or appropriate permissions
        var sharerLevel = await GetAccessLevelAsync(ownerId, documentId);
        if (sharerLevel != AccessLevel.Owner)
            throw new UnauthorizedException("Only owners can share");

        // Find or create user by email
        var targetUser = await FindUserByEmailAsync(targetEmail);
        await _store.UpsertAsync(targetUser.Id, documentId, level);

        // Invalidate cache
        await _cache.RemoveAsync($"perm:{documentId}:{targetUser.Id}");

        // Send sharing notification
        await NotifyDocumentSharedAsync(documentId, ownerId, targetUser, level);
    }
}

public enum AccessLevel
{
    None,
    Viewer,
    Commenter,
    Editor,
    Owner
}

13. Document Export, Rendering, and the Toolbar

Beyond the core editing experience, Google Docs provides rich document rendering, a formatting toolbar, and export to multiple formats. The document is stored as a plain text operation log, but it must be rendered with formatting (bold, italic, headings, lists, tables, images) in the browser. This rendering is handled by a client-side document renderer that interprets formatting operations alongside text operations.

Formatting as Operations

Formatting in Google Docs is represented as additional operation types beyond insert and delete. A formatting operation specifies a character range and the style to apply or remove. The document renderer applies these formatting operations on top of the text to produce the rich visual output.

// Formatting Operations — Extended Operation Types
public class FormatOperation
{
    public OpType Type { get; set; } // FormatApply, FormatRemove
    public int StartPosition { get; set; }
    public int EndPosition { get; set; }
    public FormatStyle Style { get; set; }
    public object Value { get; set; } = null!;
    public string UserId { get; set; } = "";
}

public enum FormatStyle
{
    Bold,
    Italic,
    Underline,
    Strikethrough,
    FontFamily,
    FontSize,
    ForegroundColor,
    BackgroundColor,
    Heading1,
    Heading2,
    Heading3,
    NormalText,
    BulletList,
    NumberedList,
    BlockQuote,
    CodeBlock,
    Link,
    Image,
    Table
}

// Client-side document renderer
public class DocumentRenderer
{
    public RenderedDocument Render(DocumentState state, List<FormatOperation> formats)
    {
        var rendered = new RenderedDocument();
        var chars = state.GetText();

        // Apply formatting to character ranges
        var styleMap = new Dictionary<int, List<FormatStyle>>();
        foreach (var fmt in formats.Where(f => f.Type == OpType.FormatApply))
        {
            for (int i = fmt.StartPosition; i < fmt.EndPosition; i++)
            {
                if (!styleMap.ContainsKey(i))
                    styleMap[i] = new List<FormatStyle>();
                styleMap[i].Add(fmt.Style);
            }
        }

        // Generate HTML
        var sb = new StringBuilder();
        for (int i = 0; i < chars.Length; i++)
        {
            if (styleMap.TryGetValue(i, out var styles))
            {
                foreach (var s in styles)
                    sb.Append(GetOpeningTag(s));
            }
            sb.Append(WebUtility.HtmlEncode(chars[i].ToString()));
        }

        rendered.Html = sb.ToString();
        return rendered;
    }
}

Export Pipeline

Export to PDF and other formats is handled by a server-side rendering pipeline. The document state is fetched from the store, formatting is applied, the document is rendered to HTML, and then converted to the target format using libraries like wkhtmltopdf for PDF or Open XML SDK for DOCX. The export is performed asynchronously for large documents, and the result is cached and delivered via a download link.

14. Caching, CDN, and Performance Optimization

Performance is critical for Google Docs. Users expect instant feedback when typing, and any delay in rendering remote operations is immediately noticeable. The system uses multiple layers of caching and optimization to achieve sub-50-millisecond local operation latency and sub-100-millisecond remote operation propagation.

Multi-Layer Cache Architecture

// Multi-Layer Cache Service
public class DocumentCacheService
{
    private readonly IMemoryCache _l1Memory;
    private readonly IDistributedCache _l2Redis;
    private readonly IDocumentStore _l5Store;

    public async Task<DocumentState> GetDocumentAsync(string docId)
    {
        // L1: In-memory (per server instance)
        if (_l1Memory.TryGetValue<DocumentState>($"doc:{docId}", out var l1))
            return l1;

        // L2: Redis
        var l2 = await _l2Redis.GetAsync<DocumentState>($"doc:{docId}");
        if (l2 != null)
        {
            _l1Memory.Set($"doc:{docId}", l2, TimeSpan.FromMinutes(5));
            return l2;
        }

        // L5: Persistent store
        var l5 = await _l5Store.GetDocumentAsync(docId);
        await _l2Redis.SetAsync($"doc:{docId}", l5, TimeSpan.FromMinutes(30));
        _l1Memory.Set($"doc:{docId}", l5, TimeSpan.FromMinutes(5));
        return l5;
    }

    public async Task InvalidateAsync(string docId)
    {
        _l1Memory.Remove($"doc:{docId}");
        await _l2Redis.RemoveAsync($"doc:{docId}");
    }
}

Performance Benchmarks

15. Scaling to Billions of Documents

Google Docs serves 3 billion documents and 500 million monthly active users. Scaling to this level requires careful attention to data partitioning, horizontal scaling of stateless services, and intelligent routing of stateful operations.

Data Partitioning Strategy

Documents are partitioned by document ID using consistent hashing. Each collaboration server instance is responsible for a range of document IDs. When a client connects, the load balancer routes the WebSocket connection to the server instance that owns the document's hash range. This ensures all operations for a given document are handled by a single server, eliminating the need for distributed locks.

// Consistent Hashing for Document Routing
public class DocumentRouter
{
    private readonly ConsistentHashRing<string> _ring;

    public DocumentRouter(List<string> serverInstances)
    {
        _ring = new ConsistentHashRing<string>(serverInstances, replicas: 150);
    }

    public string GetServerForDocument(string docId)
    {
        return _ring.GetNode(docId);
    }

    public List<string> GetResponsibleServers(string docId, int replication = 3)
    {
        return _ring.GetNodes(docId, replication);
    }
}

// Load Balancer Configuration (Envoy)
// Routes WebSocket connections to the correct server based on document ID
public class StickySessionLoadBalancer
{
    public string RouteConnection(string docId, string clientIp)
    {
        string targetServer = _router.GetServerForDocument(docId);

        // Set cookie for sticky sessions
        return targetServer;
    }
}

Horizontal Scaling Metrics

Hot Document Handling

Some documents are extremely popular — a classroom worksheet being edited by 30 students, a shared meeting agenda with 100 participants. These "hot" documents require special handling: the collaboration server pre-loads the document state into memory, the operation log is kept entirely in RAM, and broadcasts are batched aggressively to reduce Redis pub-sub overhead. If a document exceeds 100 concurrent editors, the server may shard the broadcast across multiple Redis channels.

16. Security, Encryption, and Abuse Prevention

Security for Google Docs is paramount — users store sensitive documents including legal contracts, medical records, and corporate strategy documents. The system must protect data in transit, at rest, and during processing.

Security Layers

// Operation Integrity Verification
public class OperationSecurityService
{
    private readonly HMACSHA256 _hmac;

    public Operation SignOperation(Operation op, string userSecretKey)
    {
        var hmac = new HMACSHA256(Encoding.UTF8.GetBytes(userSecretKey));
        string payload = $"{op.Type}:{op.Position}:{op.Text}:{op.UserId}:{op.Seq}";
        byte[] hash = hmac.ComputeHash(Encoding.UTF8.GetBytes(payload));
        op.Signature = Convert.ToBase64String(hash);
        return op;
    }

    public bool VerifyOperation(Operation op, string userSecretKey)
    {
        var hmac = new HMACSHA256(Encoding.UTF8.GetBytes(userSecretKey));
        string payload = $"{op.Type}:{op.Position}:{op.Text}:{op.UserId}:{op.Seq}";
        byte[] expected = hmac.ComputeHash(Encoding.UTF8.GetBytes(payload));
        return Convert.ToBase64String(expected) == op.Signature;
    }

    public async Task<bool> CheckRateLimitAsync(string userId)
    {
        string key = $"ratelimit:{userId}";
        int count = await _redis.IncrementAsync(key);
        if (count == 1)
            await _redis.ExpireAsync(key, TimeSpan.FromSeconds(1));

        return count <= 1000; // max 1000 ops/sec per user
    }
}

17. Real-Time Collaboration: OT vs CRDTs Deep Dive

Operational Transformation and Conflict-Free Replicated Data Types represent two fundamentally different philosophies for solving collaborative editing. OT centralizes coordination: every operation flows through a server that transforms it against concurrent operations before broadcasting. CRDTs decentralize: every character carries a globally unique identity and a fractional position, allowing independent merging without coordination. Understanding when to use each is a key differentiator for senior engineers.

Transformation Overhead and Latency

OT's per-operation cost scales linearly with the number of concurrent pending operations. When two users type simultaneously on a document with five pending operations, each new operation must be transformed against all five — an O(n) cost per operation. CRDTs avoid this entirely: inserting a character requires computing a fractional midpoint between two neighbors, an O(1) operation regardless of how many other edits are in flight. However, OT's overhead is negligible in practice because the pending operation window is typically fewer than ten operations, and transformation is a simple arithmetic comparison of position integers.

Memory and Storage Trade-Offs

This is where OT has a clear advantage for text-heavy documents. A plain-text character occupies one byte. An OT character with its position index occupies roughly two to three bytes. A CRDT character, by contrast, carries a unique ID (user ID + logical clock, 16 bytes), a fractional position (variable-length numerator and denominator, 8 to 32 bytes), and a tombstone flag — totalling 24 to 50 bytes per character. For a 500KB document, OT uses approximately 1.5MB of metadata while CRDTs consume 12 to 25MB. This overhead also impacts network bandwidth: transmitting a CRDT operation requires sending the full character identity, whereas an OT operation sends only a position integer and the text content.

// OT Transform — Comparing cost against CRDT midpoint insertion
public class CollaborationCostAnalysis
{
    /// OT: Transform one operation against N pending server operations
    /// Cost is linear in the number of pending operations
    public static Operation TransformOtcost(Operation clientOp, List<Operation> pending)
    {
        Operation result = clientOp;
        foreach (var serverOp in pending)
        {
            if (serverOp.UserId != clientOp.UserId)
                result = OTEngine.Transform(result, serverOp);
        }
        return result;
    }

    /// CRDT: Insert a character — constant time regardless of document state
    /// Only requires finding two adjacent positions (skiplist or tree: O(log n))
    public static CRDTChar InsertCRDTcost(
        string userId, long clock, Fraction after, Fraction before, char ch)
    {
        Fraction pos = Fraction.Midpoint(after, before);
        return new CRDTChar
        {
            Character = ch,
            UserId = userId,
            Clock = clock,
            Position = pos,
            IsDeleted = false
        };
    }

    /// Memory comparison for a 500,000 character document
    public static void CompareMemoryUsage()
    {
        long plainTextBytes = 500_000L;
        long otMetadataBytes = 500_000L * 3;     // ~1.5 MB
        long crdtMetadataBytes = 500_000L * 32;   // ~16 MB
        Console.WriteLine($"OT overhead:   {otMetadataBytes / 1_048_576.0:F1} MB");
        Console.WriteLine($"CRDT overhead: {crdtMetadataBytes / 1_048_576.0:F1} MB");
    }
}

The practical decision often comes down to the deployment model. If you control the server and all clients connect through it (the Google Docs model), OT provides lower memory usage, simpler revision history, and immediate deletion semantics. If you need true offline-first operation where multiple devices merge independently without ever contacting a server (the Apple Notes or Figma model), CRDTs are the only viable choice. Many modern production systems use a hybrid approach: CRDTs on the client for local merging with a central server for persistence, access control, and revision history — combining the offline resilience of CRDTs with the storage efficiency and governance of a server-managed system.

18. Offline Sync and Conflict Resolution

Offline editing is where the collaborative editing system faces its hardest challenge. When a user disconnects, edits locally, and reconnects, the system must reconcile potentially dozens of local operations against any concurrent changes made by other users. The reconciliation must be seamless — the user should never see a conflict message for normal editing scenarios. Only genuine semantic conflicts (like a document being deleted while offline) should require user intervention.

The Synchronization Pipeline

When a client reconnects, it performs a five-step synchronization process. First, it sends its local version vector to the server. Second, the server identifies all operations the client has missed since its last acknowledged version. Third, the server transforms each of the client's queued operations against the missed operations using the OT transform function. Fourth, if all transformations succeed, the server applies each transformed operation to the canonical state and broadcasts it to other connected clients. Fifth, the server sends an acknowledgment for each accepted operation, allowing the client to clear its local queue. This entire pipeline completes in under 200 milliseconds for typical offline sessions with fewer than 100 queued operations.

Handling Edge Cases During Offline

Several edge cases require special handling beyond the standard OT reconciliation. If the document was deleted by another user while the offline client was editing, the server cannot transform against a non-existent document — it returns a "document deleted" error and the client offers to save the local version as a new document. If the offline user's permissions were revoked, the server rejects all queued operations and closes the connection. If the document was renamed or moved to a different folder, the server applies those metadata changes alongside the text operations. The most subtle edge case is when the offline period exceeds the server's operation retention window (typically 72 hours for the in-memory operation log). In this case, the server must rebuild the client's state from the latest snapshot, which may be slower but still correct.

// Full Offline-to-Online Reconciliation Engine
public class OfflineReconciliationService
{
    private readonly IOperationStore _opStore;
    private readonly IDocumentStateStore _stateStore;
    private readonly IOTEngine _otEngine;
    private readonly IBroadcastService _broadcaster;

    public async Task<ReconciliationResult> ReconcileAsync(
        string docId, string userId, VersionVector clientVector,
        List<Operation> queuedOps)
    {
        // Step 1: Get all operations the client has missed
        var serverOps = await _opStore.GetOperationsSinceAsync(
            docId, clientVector);

        // Step 2: Check for document-level conflicts
        var docMeta = await _stateStore.GetDocumentMetaAsync(docId);
        if (docMeta.IsDeleted)
            return ReconciliationResult.DocumentDeleted(docMeta.DeletedBy);

        if (!docMeta.IsActive)
            return ReconciliationResult.DocumentDeactivated();

        // Step 3: Transform each queued op against server ops
        var transformedOps = new List<TransformedOperation>();
        var currentDocState = await _stateStore.GetDocumentStateAsync(docId);

        foreach (var queuedOp in queuedOps)
        {
            var transformed = queuedOp;
            bool transformSuccess = true;

            foreach (var serverOp in serverOps)
            {
                if (serverOp.UserId != userId)
                {
                    try
                    {
                        transformed = _otEngine.Transform(transformed, serverOp);
                    }
                    catch (TransformException ex)
                    {
                        transformSuccess = false;
                        break;
                    }
                }
            }

            if (transformSuccess)
            {
                // Apply to canonical state
                currentDocState.ApplyOperation(transformed);
                transformedOps.Add(new TransformedOperation
                {
                    Original = queuedOp,
                    Transformed = transformed
                });
            }
            else
            {
                return ReconciliationResult.TransformConflict(
                    queuedOp, serverOps);
            }
        }

        // Step 4: Persist and broadcast each transformed operation
        foreach (var to in transformedOps)
        {
            await _opStore.AppendAsync(docId, to.Transformed);
            await _broadcaster.BroadcastAsync(docId, to.Transformed);
        }

        // Step 5: Acknowledge all original operations
        return ReconciliationResult.Success(
            transformedOps.Select(t => t.Original.SequenceNumber).ToList());
    }
}

Conflict Resolution UX Patterns

19. Interview Questions and Answers

The following questions are commonly asked in system design interviews for senior and staff engineer roles. Each answer is designed to demonstrate depth of understanding and practical experience.

Q1: Design a real-time collaborative text editor like Google Docs. Walk me through the architecture.

Answer: The system has four major layers: the client-side editor (with a local OT engine and IndexedDB cache), the collaboration server (with per-document mutex and operation transformation), the document storage layer (Bigtable/Spanner for current state, Cloud Storage for revision history), and the real-time communication layer (WebSocket with Redis pub-sub for cross-server broadcasting). The flow is: client captures keystroke, generates operation, sends via WebSocket, server transforms against pending ops, applies to canonical state, broadcasts to other clients. The critical invariant is operation serialization per document via the per-document mutex. Revision history uses compressed deltas with periodic full snapshots.

Q2: What is the difference between OT and CRDTs? When would you choose one over the other?

Answer: OT transforms operations at a central server to maintain consistency. It requires coordinated transformation and works best with a centralized architecture. CRDTs assign globally unique IDs to each character and use mathematical properties (commutativity, associativity, idempotency) to guarantee convergence without coordination. Choose OT when you have a server and want simpler memory usage (no tombstones). Choose CRDTs when you need P2P support, offline-first architecture, or are editing structured data like spreadsheets. Modern systems like Figma use CRDTs because their multi-device offline requirement makes server-dependent OT impractical.

Q3: How does Google Docs handle 100+ concurrent editors without performance degradation?

Answer: The collaboration server uses per-document mutex for serialization, which is in-memory and non-blocking (no disk I/O during operation processing). Operations are tiny (~50 bytes) so the transformation is O(n) in the number of concurrent pending ops, which is small. Broadcasting uses Redis pub-sub to distribute across servers. The server batches broadcasts every 100ms or 50 operations. For extremely hot documents (100+ editors), the document's entire state is pinned in memory and the operation log is kept in RAM with periodic flush to durable storage.

Q4: Design the offline editing and synchronization system for Google Docs.

Answer: When a document is opened, the full state is cached in IndexedDB via a Service Worker. Local edits are applied immediately using a local OT engine and queued in IndexedDB. On reconnection, queued operations are sent to the server, which transforms them against any concurrent operations from other users. If the transform succeeds, the operation is accepted and broadcast. If a conflict occurs (e.g., document deleted), the server returns an error and the client notifies the user. The key challenge is ensuring the local OT engine is identical to the server's, so local transformations during offline editing produce the same result the server would produce.

Q5: How is revision history stored efficiently for billions of documents?

Answer: Revisions are stored as compressed deltas — the operations that changed the document — not full document copies. Full snapshots are taken every 50 revisions for efficient recovery. Using gzip compression, operation deltas average 500 bytes and full snapshots average 10KB. For 3B documents with 100 revisions each, the total storage is approximately 210TB (150TB for deltas, 60TB for snapshots). Recovery of a specific revision requires loading the nearest snapshot and replaying deltas, which for 50 revisions takes under 100ms.

Q6: How would you handle the cursor and presence system?

Answer: Cursor positions are broadcast on every cursor movement (throttled to 30Hz). Each cursor is identified by user ID, position, color, and display name. Cursor operations are not part of the OT log — they are ephemeral and only matter while the user is connected. The presence service stores active cursors in Redis with a short TTL (30 seconds). When a user stops moving their cursor, the TTL expires and other users stop seeing it. Cursor positions must be transformed using the same OT logic as text operations to ensure they point to the correct character after remote edits.

Q7: Explain the permission model and how it is enforced in the collaboration server.

Answer: Google Docs has four roles: Owner, Editor, Commenter, Viewer. Permissions are checked at three points: (1) WebSocket connection establishment — the server validates the auth token and document access level before accepting the connection; (2) Operation processing — the server checks that the user has Editor or Owner access before applying text operations; (3) Export and sharing — only editors can export, only owners can share. Permissions are cached in Redis for 5 minutes to reduce database lookups. When a permission is revoked, the cache is invalidated and the server immediately closes any active WebSocket connections for that user on that document.

Q8: What are the trade-offs of using a centralized server vs P2P for collaborative editing?

Answer: Centralized (Google Docs approach): simpler to implement, single source of truth, easy revision history, but creates a single point of failure and requires server for all edits. P2P (CRDT approach): no single point of failure, works offline by design, no server costs, but harder to implement, requires complex garbage collection, revision history must be explicitly maintained, and security/trust model is harder. Most production systems use a hybrid: client-side CRDTs for offline editing with a central server for synchronization, persistence, and access control.

Q9: How do you test an OT implementation for correctness?

Answer: Testing OT requires several strategies: (1) Unit tests for all 6 transformation cases (insert-insert, insert-delete, delete-insert, delete-delete, plus same-position variants); (2) Property-based testing with randomly generated operation sequences to verify the convergence property — apply operations in different orders and verify the result is identical; (3) Integration tests with simulated multi-client scenarios using recorded operation logs from real usage; (4) Chaos testing with simulated network partitions, reordering, and duplicate delivery. The convergence property test is the most important — generate 1000 random operation sequences, apply them to the same starting state, and verify all produce the same result.

Q10: How would you design the system to handle a document being edited on multiple devices by the same user?

Answer: Each device maintains its own local OT engine and connects via a separate WebSocket. The server treats each device as an independent client. The user's operations from different devices are serialized through the same per-document mutex, so they apply in the correct order. The version vector tracks per-device (not per-user) versions to handle cases where one device goes offline. When both devices come online, their queued operations are independently transformed against the server state. The user sees a single consistent document across all devices because all operations converge to the same state.

Frequently Asked Questions

What is Operational Transformation (OT) in Google Docs?

Operational Transformation is the core algorithm that enables real-time collaborative editing. When two users edit the same document simultaneously, the server transforms their concurrent operations against each other before applying and broadcasting, ensuring all clients converge to the same document state. The algorithm handles six transformation cases covering insert-insert, insert-delete, and delete-delete scenarios.

How does Google Docs handle 100+ concurrent editors?

Google Docs uses a centralized server that serializes operations per document using an in-memory mutex. Each operation is transformed against concurrent operations using OT, then broadcast via WebSocket to all connected clients. The server batches broadcasts every 100ms or 50 operations. For extremely hot documents, the entire state is pinned in memory with Redis pub-sub distributing broadcasts across server instances.

What is the difference between OT and CRDTs?

OT requires a central server to transform operations and coordinate state. CRDTs (Conflict-Free Replicated Data Types) allow every client to merge independently without coordination. OT is simpler for text editing with a server; CRDTs excel in peer-to-peer, offline-first, and structured data scenarios. Google Docs uses OT; Figma and Notion use CRDTs.

How does offline editing work in Google Docs?

Local edits are stored in IndexedDB and queued as operations. The full document state is cached via Service Workers. On reconnection, queued operations are sent to the server which transforms them against any concurrent changes from other users using OT and reconciles the state. If a conflict occurs (e.g., document deleted), the server returns an error for manual resolution.

How is revision history stored efficiently in Google Docs?

Revisions are stored as compressed deltas (gzip, averaging 500 bytes each). Full document snapshots are taken every 50 revisions (averaging 10KB compressed). For 3 billion documents with 100 revisions each, total revision storage is approximately 210TB. Recovery of a specific revision loads the nearest snapshot and replays subsequent deltas.

What happens when two users type at the same position simultaneously?

The server transforms both operations against each other using defined transformation functions. When both are inserts at the same position, a tiebreaker based on user ID determines the order. Both insertions appear in the final document in a deterministic order, and all clients see the same result due to the convergence property of OT.

How does Google Docs handle document permissions?

A permission service manages access control lists (ACLs) for each document. Roles include Owner, Editor, Commenter, and Viewer. Permissions are checked at connection time, during operation processing, and for export/sharing actions. The permission cache in Redis reduces database lookups, and cache invalidation immediately revokes access when permissions change.