01 · OWNERSHIP
System of record vs derived data
DB、blob、change log 拥有事实；cache、read replica、CDN 提供派生读路径。每份副本都要回答重建、陈旧和失效。
WEEK 02 · 2026.08.03—08.09 · WRITER GATE
读扩展、派生数据与文件路径
Distributed Cache 是唯一基础设施锚点。Dropbox 是完整覆盖的应用案例，用来验证 blob / metadata 分离、resumable upload、sync 与 conflict；它不是一根并列架构主柱。
能力主线
顺序固定：先定义权威状态，再设计读路径；先建立单节点不变量，再讨论复制和分片；最后用 Dropbox 检查机制能否迁移到大对象与多设备状态。
02 · SCALE
Replication 与 partitioning 分工
复制提高故障容忍与读容量；分片扩大总容量与吞吐。consistent hashing 降低 remap，但不消灭热点。
03 · FILE PATH
Control plane 与 data plane
应用服务签发有限权限并提交 metadata；blob bytes 直达对象存储/CDN。multipart、sync cursor 与 conflict 都有明确恢复。
项目角色
两题都完整覆盖，但深度权重不同。Distributed Cache 承担架构教学和 45 分钟主 mock；Dropbox 承担应用迁移与 25 分钟压力轮。
| 项目 | 课程角色 | 必须覆盖 | 退出证据 |
|---|---|---|---|
| Distributed Cache | Core mastery · infrastructure anchor | set/get/delete、TTL、LRU、HA、replication、partitioning、consistent hashing、hot read/write、performance、levels。 | 45 分钟完整答题；两个 failure window；三项 operational metrics。 |
| Dropbox | Full coverage · application case | blob/metadata、upload/download/share/sync、multipart resume、delta sync、security、conflict、levels。 | 25—35 分钟设计尝试；upload commit invariant；notification loss 与 concurrent edit 时序。 |
Live heading 合同
库存来自 2026-07-23 live 页面。这里只显示计数；Day 1—4 逐 heading 提供精确 fragment URL，production record 保留完整 disposition 表。
DISTRIBUTED CACHE · LIVE INVENTORY
23 个可定位 heading，零跳过
required reading 11 · deep dive 7 · level expectation 5。完整 disposition 分配在 Day 1—2，从第一个精确小节打开。
DROPBOX · LIVE INVENTORY
21 个可定位 heading，零跳过
required reading 13 · deep dive 4 · level expectation 4。完整 disposition 分配在 Day 3—4，从第一个精确小节打开。
DDIA 问题地图
没有整章阅读。每一条都从项目暴露的问题出发，直接进入第二版中文站的精确 subsection。
| 项目问题 | 精确小节 | 改变的设计 | 读完必须回答 |
|---|---|---|---|
| 缓存和数据库冲突时，谁拥有事实？ | Ch1 · 记录系统与派生数据 | 把业务数据库定义为 system of record，把缓存定义为可删除、可重建的派生数据；失效与重建因此成为显式契约。 | 能说出哪份状态可重建、从哪里重建，以及缓存陈旧时用户会看到什么。 |
| 为什么缓存把延迟换成内存、淘汰与丢失风险？ | Ch4 · 全内存存储 | 内存不是“更高级的数据库”；它服务极低延迟，同时要求容量边界、淘汰和故障恢复路径。 | 能把 <10ms SLO、可用内存、value 大小、复制因子和节点数放进同一个容量判断。 |
| 缓存写入要等多少个副本确认？ | Ch6 · 同步复制与异步复制 | 同步确认缩小丢写窗口但扩大尾延迟与不可用面；异步复制满足题目的 eventual consistency，但必须暴露 replica lag。 | 能画出 primary ACK 后、replica 收到前 primary 崩溃的丢失窗口。 |
| 1TB 键值如何落到节点，扩缩容时如何减少搬迁？ | Ch7 · 按键的哈希分片 | 先以哈希分片解释均匀性，再比较固定分片与一致性哈希的成员变更成本。 | 能说明 key → shard → node 的路由链，并区分 logical shard 与 physical node。 |
| 为什么 modulo hashing 在节点数变化时危险？ | Ch7 · 一致性哈希 | 采用虚拟节点和版本化 ring，限制成员变更时的 key remap；迁移期间保留双读或 forwarding 窗口。 | 能说出 consistent hashing 解决重映射，不解决单个 hot key。 |
| hash 均匀为什么仍挡不住 hot key？ | Ch7 · 倾斜的工作负载与缓解热点 | 读热点用副本、本地/请求级合并和 key replication；写热点必须改状态模型、分桶或局部聚合。 | 能分别处理 hot read 与 hot write，且不把“加虚拟节点”当答案。 |
| 客户端还是代理知道 key 在哪？ | Ch7 · 请求路由 | 客户端路由少一跳但 ring 更新复杂；代理路由集中控制但增加一跳和瓶颈。选型必须绑定客户端数量与变更频率。 | 能描述 ring version 不一致时的 MOVED/redirect、重试与幂等边界。 |
| Dropbox 如何按 user 快速列出被分享的文件？ | Ch4 · 多列索引与二级索引 | 不要扫描 file.sharelist；建立 userId + fileId 的反向关系或索引，并明确它是权威关系还是派生视图。 | 能画出 owner files 与 shared files 两条查询路径及更新原子性。 |
| 多设备离线后如何重新汇合，不依赖通知绝不丢？ | Ch6 · 同步引擎与本地优先软件 | 通知只做唤醒，游标化 change log 才是修复路径；设备必须携带 base version 和 last cursor。 | 能追踪断网、通知丢失、重复拉取、重放后的最终状态。 |
| 两个设备并发改同一 base version 时如何处理？ | Ch6 · 最后写入胜利（丢弃并发写入） | 拒绝依赖客户端时钟的 silent LWW；以 server version 检测冲突并保留 conflict copy 或交给用户合并。 | 能给出 baseVersion、currentVersion、conflict copy 的用户可见语义。 |
固定时间合同
每天 08:30 起床不安排课程。系统设计、算法和口述三块互不挤占；日页内的 minute-by-minute 安排总量与窗口完全一致。
| 时间 | 不变合同 | 本周证据 |
|---|---|---|
| 08:30 | Wake time | 不塞入预读、音频或算法。 |
| 08:50—10:55 | System design | 目标句、闭卷尝试、精确阅读、决策卡、无稿 close。 |
| 14:30—16:15 | Three NeetCode problems | 连续 Two Pointers tag；每题 35 分钟，21 个必做 slot。 |
| 20:30—21:15 | Oral / Q&A / mock repair | 录音 timestamp + 一条 repair sentence。 |
7 天执行
Mon/Tue 打穿基础设施；Wed/Thu 完整覆盖应用；Fri 迁移；Sat mock；Sun 证据修复并在 writer gate 停止。
MON · 08.03
Distributed Cache：先定义事实，再画读路径
闭卷起手后完整读到 HLD。今天建立 cache entry、TTL、LRU、source of truth 与单节点正确性，不提前跳到集群名词。
进入TUE · 08.04
Distributed Cache：复制、分片、热点与故障
完整覆盖六个 live deep dives 与 level expectation。今天的主线是 key routing、replication、rebalancing、hot read/write 和 p99。
进入WED · 08.05
Dropbox：把 blob path 与 metadata path 分开
Dropbox 是 full-coverage application case。完整读到 HLD，用它验证缓存、派生视图、blob/metadata 分离、download CDN 与 sync cursor，不把它升级为第二根架构主柱。
进入THU · 08.06
Dropbox：续传、提交、同步与冲突
完整覆盖 Dropbox 三个 live deep dives 和 Staff+ expectation。重点是 multipart upload 的可信完成、delta sync、版本冲突、安全边界与故障回收。
进入FRI · 08.07
横向迁移：读扩展、缓存与大对象的边界
今天不再增加项目。把 Distributed Cache 的基础设施机制迁移到 Dropbox：metadata cache、CDN、source of truth、读副本、分片与 large-object path。
进入SAT · 08.08
完整 Mock：基础设施主线 + 应用压力轮
45 分钟 Distributed Cache 是主面；随后 25 分钟 Dropbox 压力轮只验证 blob/metadata、resumable upload、sync 与 conflict 的迁移深度。
进入Frontier source 决策
只保留会改变具体系统决定的官方材料。
ACCEPTED · AWS S3
Multipart Upload Overview
它把模糊的“分块上传”收紧为 uploadId、part number/ETag、Complete/Abort 与 incomplete-upload 清理契约，直接改变续传和提交状态机。
REJECTED · UNRELATED AI
不强塞 Agent / LLM 材料
OpenAI Harness Engineering、Anthropic effective agents 与本周 cache ownership、blob commit、sync conflict 没有直接设计作用，因此拒绝进入日程。
Detailed lecture notes, audio, recall scripts, PDFs, Staff Q&A, and mock packs are archived locally and are intentionally not published on this site.