Design Google Docs: Back-of-the-Envelope Estimates

When an interviewer asks you to design a real-time collaborative editor like Google Docs, they are not looking for a superficial list of UI components. They want to see if you can evaluate how concurrent real-time actions scale across thousands of connected users. Starting with back-of-the-envelope numbers gives you a concrete foundation for making key architectural choices, such as choosing between WebSocket persistent connections and long polling, or deciding between Operational Transformation (OT) and Conflict-free Replicated Data Types (CRDTs).

By laying out explicit assumptions about daily active users, editing behavior, and data payloads, you transform an abstract problem into a set of engineering requirements. You can practice system design questions in a mock interview to build confidence in walking through these estimations under realistic time constraints.

Establishing Core Usage Assumptions

To build a realistic capacity model, begin with explicit assumptions about user activity. Assume the platform serves 100 million Daily Active Users (DAU). Out of these 100M active users, assume 10 million edit documents concurrently during peak hours. Furthermore, assume an average user participates in active document sessions for roughly 1 hour per day.

In terms of document access pattern, assume that 90% of active documents have only 1 or 2 simultaneous editors. However, the system must support power scenarios where a single popular document or team workspace has up to 100 simultaneous active editors. Every active user generates edits at an average typing speed of 3 keystrokes per second while actively typing, but users spend only about 20% of their session time actively typing. This produces an effective average of 0.6 keystrokes per second per connected active user.

Traffic Estimates for Operations and Presence

Real-time collaborative editing involves two distinct streams of data: document operations (keystrokes, text insertions, deletions) and presence updates (cursor movements, text selections, active user lists). Estimating both streams separately is essential because they have very different network overheads and durability requirements.

For 10 million concurrent active users generating 0.6 keystrokes per second, the system handles a baseline operation write volume of 6 million operations per second globally. Each edit operation payload includes the operation type (insert or delete), target position or character ID, document identifier, sequence version, and character value. Assume a compact payload size of 100 bytes per operation over a binary WebSocket frame. Multiplying 6 million operations per second by 100 bytes yields 600 megabytes per second (4.8 Gbps) of incoming write bandwidth.

Presence traffic is typically throttled on the client side to 2 updates per second per active user to avoid overwhelming the network. At 10 million concurrent active users, this yields 20 million presence updates per second. Assuming 50 bytes per presence payload, presence generates 1,000 megabytes per second (8 Gbps) of ingress traffic. Because presence updates are ephemeral and do not need persistent storage, they flow through a light pub/sub layer rather than a transactional persistence pipeline.

Storage Estimates for Operational Logs and Document Snapshots

Collaborative editors avoid overwriting full document state on every keystroke. Instead, they store an append-only log of granular operations and periodically create document snapshots.

Assume 100 million active users produce an average of 500 edit operations each day, resulting in 50 billion operations daily. At 100 bytes per operation, the operational log grows by 5 terabytes per day (uncompressed). Over a one-year retention period, operational log storage requires roughly 1.82 petabytes.

Document snapshots prevent clients and servers from having to replay millions of historical operations from scratch when opening a file. Assume 1 billion total documents stored in the system, with an average plain text and structure snapshot size of 200 kilobytes. Storing one snapshot per document requires 200 terabytes. If the system retains the last 10 full snapshots per document for revision history, storage needs scale to 2 petabytes. Adding index overhead and 3x replication across storage nodes brings the total durable storage budget to approximately 6.6 petabytes.

Memory and Server Instance Sizing

Sizing the WebSocket gateway tier requires evaluating memory limits for persistent concurrent TCP connections. Holding 10 million concurrent open WebSocket sockets requires socket buffer allocations on the host servers. A Linux server optimized for high socket counts typically uses around 10 kilobytes of memory per open connection including OS TCP buffers and application memory.

For 10 million concurrent connections, the network gateway fleet requires 100 gigabytes of RAM strictly dedicated to connection overhead. Factoring in a 4x safety factor for memory spikes during reconnection storms, you need 400 gigabytes of operational memory. Distributed across gateway nodes running on 64 GB RAM instances, a baseline fleet of 10 to 15 gateway instances can comfortably manage the connection pool.

For stateful session servers running conflict resolution algorithms, each active document is loaded into memory. Assuming 2 million active documents at any peak moment, with each active session consuming 2 megabytes of RAM for operation buffering and client state, the document session tier requires 4 terabytes of memory. Using the free system design playground, you can visualize how load balancers route incoming WebSocket traffic across gateway nodes and stateful session shards.

How the Numbers Dictate System Architecture Choices

The back-of-the-envelope calculations directly drive three fundamental architectural decisions:

1. Persistent WebSockets over HTTP Polling: Handling 6 million operation writes and 20 million presence events per second makes standard HTTP requests far too costly due to header overhead (often 1 KB per request). WebSockets reduce frame headers to just 2 to 14 bytes, preserving bandwidth.
2. Stateful Document Sharding: At 6 million operations per second globally, running conflict resolution against a single centralized database would create massive lock contention. The numbers demand routing all edits for Document ID X to a dedicated session server instance that holds the single authority for transformation ordering.
3. Memory-First Conflict Resolution with Async Persistence: Writing every keystroke directly to durable disk before acknowledging the client would push write latency past 100 milliseconds. The session server accepts the operation in memory, broadcasts the transformed operation to peers, and streams operations asynchronously to an append-only log.

Where This Back-of-the-Envelope Approach Breaks Down

While back-of-the-envelope calculations provide clarity, naive estimates ignore real-world edge cases that can compromise system stability:

• Reconnection Storms: If a gateway node holding 500,000 WebSocket connections fails, those 500,000 clients attempt to reconnect simultaneously. The resulting traffic spike can cause cascading failures across remaining gateway servers unless managed by exponential backoff and jitter.
• Hot Document Bottlenecks: A document edited by 1,000 people during a live event breaks the assumption of low average fanout. Broadcasting 3,000 operations per second to 1,000 connected sockets from a single server generates 3 million outgoing messages per second on one host, overwhelming its network interface card.
• Operational Overhead of CRDT Metadata: Choosing CRDTs instead of Operational Transformation eliminates central server coordination but significantly increases payload size. A CRDT character payload often requires 50 to 100 bytes of metadata per single character due to unique site IDs and tombstones, multiplying bandwidth requirements by a factor of 10.

What to Say Out Loud in the Interview

To impress your interviewer, narrate your calculations and connect every number to a design choice. Here is how you can talk through your thought process:

"I am starting with capacity estimates to understand whether our bottleneck is network bandwidth, storage, or memory. Assuming 10 million peak active users generating 0.6 keystrokes per second, we are looking at 6 million write operations per second globally. Sending this volume over standard HTTP REST endpoints would introduce massive header overhead. That is why I am choosing WebSockets, which keep frame headers down to a few bytes."

"Next, looking at storage, 50 billion daily operations mean our operation log grows by 5 terabytes every day. We cannot execute relational database updates at 6 million writes per second, so I will isolate conflict resolution to in-memory session servers sharded by document ID. The session server orders operations in RAM, acknowledges the client in under 50ms, and flushes operations asynchronously to an append-only distributed log like Kafka or Cassandra."

When practicing on BuildTheSystem, state your assumptions clearly before adding components to the canvas so your design choices remain tethered to technical data.