System Design Lab

Google Docs changes shape when edit ordering becomes the constraint.

Start with one editable document. Increase collaborators, offline time, and reader fanout to see why the design needs WebSocket routing, a document room, OT/CRDT, an operation log, snapshots, and a separate presence path.

Read the source article

Normal evolution scenarios

Click left to right for the intended demo path. Each card changes the workload inputs.

Workload

These are inputs, not preset architecture stages.

Recommended shape

Current architecture path
Google Docs collaborative editing architecture diagram Whiteboard-style architecture diagram for real-time document collaboration with room ordering, operation transform, logs, snapshots, and presence fanout. Clients Realtime edge Doc coordination Recovery Storage + fanout Browsers local optimistic edits WebSocket auth + doc routing Doc room authoritative order OT / CRDT stale position repair Op log durable versions Snapshotter fast recovery Doc store metadata + blobs Presence best-effort fanout History versions + audit
Clients
Browsers optimistically apply local edits and send operations
Realtime edge
WebSocket gateway keeps connections and routes by document id
Document coordination
Document room serializes operations for one document
OT / CRDT repairs stale positions or merges offline edits
Recovery
Operation log durable ordered history
Snapshotter periodic full-document checkpoints
Storage + fanout
Document store metadata, permissions, and current body blobs
Presence fanout ephemeral cursors and viewer broadcast
History version history and recovery data

Bottlenecks

Room throughput

Stale-operation risk

Operation log

Presence fanout

Recovery cost

Why this changes

    Decision tradeoffs

    WebSocket edge

    Document room

    OT / CRDT

    Durable op log

    Snapshots

    Presence path

    Source-backed rules

    These are the durable system-design claims behind the model. The exact slider thresholds are deliberately labeled as teaching assumptions.

    Verified rule

    WebSocket fits low-latency bidirectional collaboration

    The browser and server both need to send messages without opening a fresh HTTP request for every edit or cursor update.

    MDN Web Docs
    Verified rule

    One authority per file keeps collaboration ordering understandable

    Figma describes routing all clients for a file to a multiplayer server so the system has a clear coordination point for that file.

    Figma Engineering
    Verified rule

    OT transforms operations generated against older versions

    Operational Transformation adjusts incoming operations against changes that already happened, matching the stale-position risk in the lab.

    TinyMCE
    Verified rule

    CRDTs trade central transforms for mergeable data structures

    CRDT-based editors attach stable ordering metadata so replicas can merge edits and converge even when operations arrive in different orders.

    System Design Sandbox

    Teaching assumptions

    • The thresholds are teaching thresholds, not Google production numbers.
    • One document room is the ordering point for edits; large read or presence fanout can be split away from that room.
    • Presence is modeled as best effort because cursor updates are ephemeral, unlike document operations.