Design a Collaborative Editor (Google Docs), stage 8 of 12: break it
Write the reconnect protocol
Implement the client side of reconnection. The client knows its last-seen sequence number and holds its pending ops, each with a unique id. The server can return every op after a given sequence number.
System so far· 4 parts
Select a component to see what it is responsible for and which state it owns.
- 1Editor client → Document router: WebSocket: ops, acks, remote ops, presence
- 2Document router → Document owner: Route by document id to the current owner
- 3Document owner → Postgres op log: Append ops at next seq (batched, epoch-fenced)
- Server push
- Request / response
What you need to know
0 of 1 checks done
Reconnection uses three things the design already has:
- A position: the client's last-seen sequence number.
- A replay: the log can return every op after that position, so the server doesn't need to remember the client. See Append-only logs.
- Idempotent resends: pending ops carry their original ids, so any the server already sequenced are skipped.
Check
Alice has 40 pending ops; the log has 25 ops from Bob she hasn't seen. How do her edits avoid overwriting Bob's?Two more rules: apply remote ops in sequence order and ignore any with
seq ≤ lastSeq(duplicates). And reconnect with exponential backoff plus jitter, so thousands of clients don't reconnect in the same instant. See Retries, backoff and jitter.