PROJECT A · BITLY
唯一写入，极热读取
短码唯一性、302 redirect、cache-aside、过期语义、容量判断、counter 与数据库故障。
本周 Scope
不是背两张图，而是掌握读写不对称、缓存、共享计数器、原子更新、分片路由与故障策略。
PROJECT B · RATE LIMITER
每次请求都要争用状态
部署位置、client identity、Token Bucket、Redis Lua、consistent hashing、fail-open / fail-closed。
一周结束时
| 能力 | 通过线 |
|---|---|
| 完整答题 | 任一项目 45 分钟内到达两项 Deep Dive 和 operations。 |
| 机制迁移 | 解释为什么 Bitly cache miss 可回源，而 Rate Limiter state miss 会改变保护语义。 |
| 故障判断 | 按 endpoint 风险选择 fail-open/closed，并给 timeout、fallback、metric。 |
| 英文表达 | 任一项目 8 分钟无稿讲出 scope、HLD、关键 trade-off 与 failure。 |
DDIA 定点加深
不按章节通读。只在项目暴露具体问题后进入对应小节；精确链接放在日级页面。
| 项目问题 | DDIA 小节 | 读完必须能回答 |
|---|---|---|
| Bitly 的 redirect “快”如何量化？ | Ch2 · 延迟与响应时间；平均值、中位数与百分位点 | 为什么 p99 比平均延迟更接近用户和下游容量风险。 |
| 数据库故障切副本后会发生什么？ | Ch6 · 处理节点故障；复制延迟的问题 | 刚创建的 mapping 为什么可能暂时读不到，以及如何收窄窗口。 |
| Rate Limiter 如何分片？ | Ch7 · 按键的哈希分片；偏斜与热点；请求路由 | consistent hashing 能解决重映射，为什么仍解决不了 celebrity hot key。 |
| Redis 超时到底代表什么？ | Ch9 · 故障与部分失效；超时和无界延迟 | 为什么 timeout 不能证明远端已失败，以及 fail-open/closed 的代价。 |
7 天执行
TUE · 07.28
Bitly：把 Deep Dives 全部打穿
短码生成、低延迟跳转、1B URLs / 100M DAU、数据库故障、counter 故障与 Senior level expectation。
进入THU · 07.30
Rate Limiter：原子性、分片与故障策略
完整覆盖算法、Redis 原子 read-modify-write、1M RPS 扩展、consistent hashing、hot key 与 fail-open / fail-closed。
进入本周资产
READ
完整原文
日级页面提供精确 Section 链接；周级页不堆叠小节目录。
SPEAK
讲义 + Q&A
讲义用于形成模型；Q&A 可直接作为 GPT Live interviewer 的追问语料。
PROVE
Mock + Repair
不使用空泛总分。只记录可观察的遗漏、错误假设和重答证据。
Detailed lecture notes, audio, recall scripts, PDFs, Staff Q&A, and mock packs are archived locally and are intentionally not published on this site.