01 · MESSAGING
Durable log before socket
发送 ACK、离线投递、多设备 receipt 都要落到可重放状态；WebSocket/Redis 只是投递通道。
WEEK 04 · 2026.08.17—08.23 · WRITER GATE
消息与协同状态
WhatsApp 学 connection ownership、ordering、offline delivery；Google Docs 学 operation log、concurrent edits、presence；Online Chess 先盲做再迁移，暴露权威顺序和公平时钟。
能力主线
Week 4 的关键词不是“实时”，而是“谁能决定顺序、谁拥有连接、离线之后从哪里恢复”。
02 · COLLABORATION
Operation log before document blob
Google Docs 的事实是 operation/revision；presence/cursor 是软状态；snapshot 是加速加载的派生。
03 · TRANSFER
Authority before reuse
Online Chess 可复用房间和连接，但 move/order/clock 必须由权威服务器裁决。
项目角色
周级目录只放项目首页链接，不放任何小节 fragment；具体 anchors 在 day 页面和 production record 中核对。
CORE · 25 canonical headings
核心项目，完整覆盖需求/API/数据模型/HLD/deep dives/Bad-Good-Great/invariants/failure/recovery/metrics/English recall。
CORE · 24 canonical headings
Google Docs
核心项目，完整覆盖需求/API/数据模型/HLD/deep dives/Bad-Good-Great/invariants/failure/recovery/metrics/English recall。
TRANSFER · 23 canonical headings
Online Chess
迁移项目，先盲做，再明确复用、失效假设、新瓶颈与追问。
DDIA 决策地图（无地毯式阅读）
只列问题和 subsection 名称；具体 anchor URL 在 day 页面打开并由 external checker 校验。
| 日 | 项目问题 | DDIA subsection | 改变的决定 |
|---|---|---|---|
| Day 1 | WhatsApp 发送 ACK 到底代表消息处于哪个顺序点？ | Ch10 · 逻辑时钟 | conversation 内 sequence/logical timestamp 由服务端分配；不使用客户端日历时钟决定消息顺序。 |
| Day 1 | 离线设备重连时如何判断哪些消息先发生、哪些是重复？ | Ch6 · “先发生”关系与并发 | 设备保存 last applied cursor；按 conversation sequence 补缺口，messageId/clientMessageId 幂等应用。 |
| Day 2 | last seen/presence 为什么不能作为强事实？ | Ch9 · 不可靠的时钟 | presence 是软状态，使用 TTL 和服务端观测时间；不把客户端时钟当作真实在线/离线裁决。 |
| Day 2 | connection owner 暂停后又回来，如何防止僵尸连接继续写状态？ | Ch9 · 隔离僵尸进程和延迟请求 | connection/session owner 带 fencing token；旧 owner 的延迟写入被拒绝。 |
| Day 3 | Google Docs 多人并发编辑为什么不是简单 last-write-wins？ | Ch6 · 处理写入冲突 | 文档编辑必须保留用户意图，不能用 LWW 丢弃并发操作；需要 OT/CRDT 或服务端 sequencer。 |
| Day 3 | 协同编辑的浏览器副本为什么像多主复制？ | Ch6 · 实时协作、离线优先和本地优先应用 | 本地先应用，异步同步到其他客户端；必须显式处理冲突、回放和撤销。 |
| Day 4 | Google Docs 的 OT/CRDT 具体改变哪个系统决定？ | Ch6 · CRDT 与操作变换 | operation log 存语义操作和 revision/context，而不是只存最终文本覆盖。 |
| Day 4 | 文档 room 内操作是否需要一个共享顺序？ | Ch10 · 共享日志作为共识 | 服务端 sequencer/op log 给文档操作建立单调 revision；客户端基于 revision transform/rebase。 |
| Day 4 | 协同服务进程暂停会怎样破坏锁/租约？ | Ch9 · 进程暂停 | 不要用本地进程假设持有无限租约；room ownership 需要心跳、lease expiry 和 fencing。 |
| Day 5 | Online Chess 为什么不能照搬聊天的 eventual ordering？ | Ch10 · 线性一致性 | 每盘棋的 move 必须像单对象线性化：同一 move number 只能有一个权威结果。 |
| Day 5 | 棋钟公平为什么不能相信客户端倒计时？ | Ch9 · 对同步时钟的依赖 | 客户端时钟只用于显示；超时裁决由服务器事件时间和可审计 deadline 决定。 |
| Day 6 | 两个核心 mock 里，什么时候需要共识/强顺序，什么时候不需要？ | Ch10 · 共识的实践 | 聊天按 conversation owner 建局部顺序；协同文档按 document op log 建顺序；棋局 move sequencer 是更强的权威顺序。 |
固定时间合同
沿用已验收作息：08:50—10:55 system design、14:30—16:15 三道 Sliding Window、20:30—21:15 recall/Q&A/mock。
| 时间 | Week 4 不变量 | 证据 |
|---|---|---|
| 08:50—10:55 | 系统设计主块，先闭卷再精读。 | 每天 4 个 bounded segment。 |
| 14:30—16:15 | NeetCode Sliding Window，连续单一 tag，每天 3 题。 | 21 个 data-neetcode-slot。 |
| 20:30—21:15 | recall / Q&A / mock，含核心系统英语 recall。 | day 页面和 scorecard 记录。 |
7 天执行
Week 4 到 reviewer gate 为止；不推进 Week 5。
MON · 08-17
WhatsApp：消息事实、connection ownership 与离线投递 HLD
把 WhatsApp 讲成 durable message log + device delivery state + soft presence，而不是 WebSocket 转发器。
进入TUE · 08-18
WhatsApp：多设备、连接失败、Redis 丢投递、乱序与 last seen
完整覆盖 WhatsApp deep dives：billions connections、partition by chat/user、multi-client、WebSocket failure、Redis delivery failure、out-of-order、last seen。
进入WED · 08-19
Google Docs：operation log、concurrent edits 与实时协同 HLD
把 Google Docs 从“同步文本”拆成 operation log、revision/context、transform/rebase、presence/cursor soft state。
进入THU · 08-20
Google Docs：WebSocket scale、storage compaction、load/update recovery
完整覆盖 Google Docs deep dives：millions WebSockets、storage control、additional deep dives、document load/update H4、level expectations。
进入FRI · 08-21
Online Chess：先盲做，再迁移 messaging/collaboration 的可复用与失效假设
把 Online Chess 当迁移题：可复用连接、房间、事件日志；不可复用聊天的 eventual ordering，也不可复用文档的保留冲突分支。
进入SAT · 08-22
双核心独立 Mock：WhatsApp 45 分钟 + Google Docs 45 分钟
分别完成 WhatsApp 与 Google Docs 的 45 分钟 mock；每场都含两个 deep dives、选择驱动追问和证据评分。
进入SUN · 08-23
Week 4 证据验收、英语 recall、停在 reviewer gate
只收敛 Week 4：检查 heading disposition、DDIA anchors、mock、scorecard、移动视觉，不预读 Week 5。
进入Applied AI radar 决策
REJECTED · NO SCHEDULED AI READING
不硬塞 Agent/LLM 材料
没有一手公司/原作者材料能直接改变本周长连接、协同状态、ordering、durable state 或 human/agent concurrent editing 的系统决定；因此明确不安排。
ACCEPTED SOURCES
Hello Interview + DDIA2 exact anchors
本周证据来自三个 live Hello Interview canonical inventories 和 DDIA2 的多主冲突/CRDT、时钟/暂停、顺序/一致性小节。
Detailed lecture notes, audio, recall scripts, PDFs, Staff Q&A, and mock packs are archived locally and are intentionally not published on this site.