今日固定时间表
08:30 wake 只保留起床；学习从 08:50 开始。三块窗口不互相挤占。
| 08:30 wake | 起床、早餐、准备白板；不安排预读或算法。 |
|---|---|
| 08:50—09:15 | 08:50—10:55 system design Bad/Good/Great 拆解 — Bad: socket 转发即真相；Good: durable log + pub/sub；Great: per-device cursor + fencing + idempotent replay。 |
| 09:15—09:50 | 08:50—10:55 system design 精确原文 — 读 WhatsApp potential deep dives、H4 partition subheading、levels 和 references。 |
| 09:50—10:25 | 08:50—10:55 system design 故障时序 — 连接断开、Redis 丢消息、重复 ACK、乱序到达、last seen 时钟偏差。 |
| 10:25—10:55 | 08:50—10:55 system design 恢复和指标 — 补 reconnect gap、delivery lag、duplicate rate、zombie owner rejection、presence freshness。 |
| 14:30—16:15 | NeetCode Tag · Sliding Window 三道题在下方独立算法表执行。 |
| 20:30—21:15 | 20:30—21:15 Staff 追问：multi-device、connection owner pause、out-of-order messages、last seen freshness。 |
算法模块
连续单一 NeetCode Sliding Window tag；每天 3 个 NEW slot，每题 30 分钟作答 + 5 分钟证据，正好 105 分钟。每天 timed review = 0，满足不超过 1。
| # | Problem / mode | Pattern | Invariant | Bug risk | Time | Space |
|---|---|---|---|---|---|---|
| 4 | Minimum Difference Between Highest and Lowest of K Scores NEW · 30m solve + 5m evidence | 排序后固定长度窗口 | 排序后最优 k 元组必为连续窗口。 | 窗口端点相差 k-1；k=1。 | O(n log n) | O(n) sort-dependent |
| 5 | Subarrays of Size K and Average >= Threshold NEW · 30m solve + 5m evidence | 固定长度 rolling sum | 每次判定前窗口恰有 k 项。 | 浮点平均误差；改比 sum >= k*threshold。 | O(n) | O(1) |
| 6 | Grumpy Bookstore Owner NEW · 30m solve + 5m evidence | 固定增益窗口 | baseline satisfaction 与窗口额外收益不重算。 | 把本来满意客户重复计入增益。 | O(n) | O(1) |
闭卷起手
15 分钟闭卷回答：WebSocket gateway、Redis/pubsub、durable message store 谁拥有事实？
Hello Interview 精确目录
day 页面使用 canonical data-toc-id/H4 anchors；周级 overview 不放小节链接。
| 项目 | 精确 canonical section | Disposition | 今天怎么用 |
|---|---|---|---|
| Potential Deep Dives | deep dive | move from HLD to scale/failure | |
| 1) How can we handle billions of simultaneous users? | deep dive | connection ownership and partitioning | |
| Should we partition by chat or by user? | deep dive | H4 partitioning decision under connection scale | |
| 2) What do we do to handle multiple clients for a given user? | deep dive | per-device state and receipts | |
| 3) What happens if the WebSocket connection fails? | deep dive | disconnect, reconnect, gap pull | |
| 4) What happens if Redis fails to deliver a message? | deep dive | pub/sub is delivery hint, durable log is truth | |
| 5) How do we handle out-of-order messages? | deep dive | conversation sequence and client buffering | |
| 6) How can we handle a "last seen" functionality? | deep dive | soft presence and clock caveats | |
| What is Expected at Each Level? | level expectation | calibrate interview depth | |
| Mid-level | level expectation | happy path | |
| Senior | level expectation | scale, ordering, failure | |
| Staff+ | level expectation | operational semantics and edge cases | |
| References | reference metadata | recorded but not scheduled as passive reading |
DDIA 精确决策卡
只读能改变今天设计决定的小节。
| 项目问题 | 精确 DDIA subsection | 改变的系统决定 |
|---|---|---|
| last seen/presence 为什么不能作为强事实？ | Ch9 · 不可靠的时钟 | presence 是软状态，使用 TTL 和服务端观测时间；不把客户端时钟当作真实在线/离线裁决。 |
| connection owner 暂停后又回来，如何防止僵尸连接继续写状态？ | Ch9 · 隔离僵尸进程和延迟请求 | connection/session owner 带 fencing token；旧 owner 的延迟写入被拒绝。 |
本日项目 artifacts
脚本、音频、PDF 与 mock evidence 直接从对应日打开。
今日产出、修复与英语 recall
| 课程角色 | CORE · all deep dives + Bad/Good/Great |
|---|---|
| 必须交付 | WhatsApp deep-dive matrix：connection scale/multi-device/disconnect/Redis/out-of-order/last-seen，各含 Bad-Good-Great、failure/recovery/metrics。 |
| 修复规则 | 如果答案只说“加 Kafka/Redis”，补 message sequence、device cursor、fencing token 和用户可见语义。 |
| English recall | English recall: “The socket is a delivery channel; the durable message log is the source of truth.” |
Detailed lecture notes, audio, recall scripts, PDFs, Staff Q&A, and mock packs are archived locally and are intentionally not published on this site.