Skip to content
sysgeeks

Design a Collaborative Editor (Google Docs), stage 12 of 12: defend it

Defend the guarantees

In the design review, someone asks: "Walk me through why every client ends up with the same document, and why we never lose an edit someone saw as saved. What failure would break each guarantee?"

System so far· 9 parts
123456789CLIENTEditor clientEDGEDocument routerSERVICEDocument ownerDATABASEPostgres op logLOG / STREAMPub/subSERVICEFan-out edgeCLIENTViewersOBJECT STORESnapshot storageWORKERSnapshotter

Select a component to see what it is responsible for and which state it owns.

  1. 1Editor client → Document router: WebSocket: ops, acks, remote ops, presence
  2. 2Document router → Document owner: Route by document id to the current owner
  3. 3Document owner → Postgres op log: Append ops at next seq (batched, epoch-fenced)
  4. 4Document owner → Snapshot storage: Load latest snapshot on open
  5. 5Document owner → Pub/sub: Publish sequenced ops
  6. 6Pub/sub → Fan-out edge: Per-document subscription
  7. 7Fan-out edge → Viewers: Batched frames, bounded buffers
  8. 8Snapshotter → Postgres op log: Read ops since the last snapshot
  9. 9Snapshotter → Snapshot storage: Write snapshot tagged with its seq
  • Server push
  • Request / response
  • Bulk data
  • Asynchronous

What you need to know

0 of 1 checks done

  1. Three ideas carry this design, and the same three appear in jobs and payments:

    • A single authority per unit of state: one owner per document, fenced by an epoch.
    • Custody transferred only once durable: ack after commit; clients hold ops until acked.
    • Idempotent application of anything repeatable: op ids, sequence numbers.

    Defending the guarantees means naming the failure that would break each one.

  2. Check

    Which failure would break the 'no acknowledged edit is lost' guarantee?