系统设计 Lab
当 edit ordering 成为约束时，Google Docs 的设计就会改变形态。
从一篇可编辑的文档开始。逐步增加协作者、offline 时长和读者 fanout，看看为什么这套设计需要 WebSocket 路由、一个 document room、OT/CRDT、一条 operation log、snapshot，以及一条独立的 presence 路径。
分步讲解
一步一步把它想清楚
要点
常规演进场景
从左到右点击，就是预设的演示路径。每张卡片都会改变 workload 输入。
推荐形态
当前架构路径
客户端
Browser 乐观地应用本地编辑并发送 operation
实时 edge
WebSocket gateway 维持连接，并按 document id 路由
文档协调
Document room 为单篇文档的 operation 串行排序
OT / CRDT 修复过期位置，或合并 offline 编辑
恢复
Operation log durable 的有序历史
Snapshotter 定期做整篇文档的 checkpoint
存储 + fanout
Document store metadata、权限和当前正文 blob
Presence fanout 短暂的光标和浏览者 broadcast
历史 版本历史和恢复数据
瓶颈
Room throughput
stale-operation 风险
Operation log
Presence fanout
恢复成本
为什么会变
决策权衡
有出处支撑的规则
这些是模型背后那些经得起时间考验的 system design 论断。而 slider 的具体阈值，则被刻意标注为教学用的假设。
WebSocket 适合低延迟的双向协作
browser 和 server 都需要发消息，而不必为每次编辑或光标更新都开一个新的 HTTP 请求。
MDN Web Docs每个文件一个权威方，能让协作的 ordering 保持可理解
Figma 介绍了把同一个文件的所有客户端都路由到一台 multiplayer server，从而让系统对该文件有一个清晰的协调点。
Figma EngineeringOT 会对那些基于旧版本生成的 operation 做变换
operational transform 会把进来的 operation 相对已经发生的改动做调整，正好对应这个 lab 里的 stale-position 风险。
TinyMCECRDT 用可合并的数据结构换掉了中心化的 transform
基于 CRDT 的编辑器会附带稳定的 ordering metadata，于是即便 operation 以不同顺序到达，各 replica 也能合并编辑并最终收敛。
System Design Sandbox教学用假设
- 这些阈值是教学用的阈值，不是 Google 的生产数字。
- 单个 document room 是编辑的 ordering point；大规模的读取或 presence fanout 可以从这个 room 拆出去。
- presence 被建模成 best effort，因为光标更新是短暂的，跟文档 operation 不一样。