今日固定时间表
08:30 wake 只保留起床；学习从 08:50 开始。三块窗口不互相挤占。
| 08:30 wake | 起床、早餐、准备白板；不安排预读或算法。 |
|---|---|
| 08:50—09:20 | 08:50—10:55 system design 盲做 — 不看原文，先画权威 game server、move sequencer、server clock、reconnect snapshot。 |
| 09:20—09:50 | 08:50—10:55 system design 精确原文 — 读 Online Chess visible live inventory 全部 anchors，包括 H4 matchmaking failure subheadings。 |
| 09:50—10:25 | 08:50—10:55 system design 迁移差异 — changed requirements、invalid reuse assumptions、new bottlenecks、浅层迁移追问。 |
| 10:25—10:55 | 08:50—10:55 system design transfer close — 输出 8 分钟 Online Chess transfer answer：ordering、clock fairness、game server ownership。 |
| 14:30—16:15 | NeetCode Tag · Sliding Window 三道题在下方独立算法表执行。 |
| 20:30—21:15 | 20:30—21:15 Online Chess 迁移口述：先讲盲做版本，再讲读完 live heading 后改了什么。 |
算法模块
连续单一 NeetCode Sliding Window tag；每天 3 个 NEW slot，每题 30 分钟作答 + 5 分钟证据，正好 105 分钟。每天 timed review = 0，满足不超过 1。
| # | Problem / mode | Pattern | Invariant | Bug risk | Time | Space |
|---|---|---|---|---|---|---|
| 13 | Longest Repeating Character Replacement NEW · 30m solve + 5m evidence | 预算型可变窗口 | windowLen - maxFreq <= k 时窗口可统一。 | 误以为收缩时必须降低陈旧 maxFreq。 | O(n) | O(alphabet) |
| 14 | Permutation in String NEW · 30m solve + 5m evidence | 固定频次匹配窗口 | 窗口长度等于 pattern 且频次差为零。 | 移出字符顺序错误；空/短字符串。 | O(n + m) | O(alphabet) |
| 15 | Frequency of the Most Frequent Element NEW · 30m solve + 5m evidence | 排序 + 成本窗口 | target*len - windowSum <= k。 | 乘法溢出；收缩后未更新 windowSum。 | O(n log n) | O(n) sort-dependent |
闭卷起手
30 分钟盲做：matchmaking、game room、submitMove、clock、leaderboard。写下哪些 WhatsApp/Docs 假设会失效。
Hello Interview 精确目录
day 页面使用 canonical data-toc-id/H4 anchors；周级 overview 不放小节链接。
| 项目 | 精确 canonical section | Disposition | 今天怎么用 |
|---|---|---|---|
| Online Chess | Understanding the Problem | required reading | transfer problem, blind first |
| Online Chess | Functional Requirements | required reading | matchmaking, realtime game, leaderboard |
| Online Chess | Non-Functional Requirements | required reading | fair clock, scale, low latency |
| Online Chess | The Set Up | required reading | scope and simplifications |
| Online Chess | Planning the Approach | required reading | requirements → entities → API → HLD |
| Online Chess | Defining the Core Entities | required reading | Player, Game, Move, Clock, MatchmakingPool |
| Online Chess | API or System Interface | required reading | join queue, submit move, watch game, leaderboard |
| Online Chess | High-Level Design | required reading | game server as authoritative sequencer |
| Online Chess | 1) Players should be able to find an opponent through skill-based matchmaking and start a game | required reading | transfer from connection queues with stronger fairness |
| Online Chess | 2) Players should be able to play a game in real time | required reading | authoritative move ordering |
| Online Chess | 3) Players should be able to view a global leaderboard and see their own rank | required reading | derived ranking state |
| Online Chess | Potential Deep Dives | deep dive | transfer pressure |
| Online Chess | 1) How do we match players fairly at scale? | deep dive | fair queue, rating windows, pool sharding |
| Online Chess | Do we need to shard the pool across Redis nodes? | deep dive | H4 matchmaking pool sharding |
| Online Chess | What happens if that Redis node goes down? | deep dive | H4 recovery for queue ownership |
| Online Chess | 2) How do we scale the game servers to 500K concurrent games? | deep dive | room placement and state ownership |
| Online Chess | 3) How do we keep the clock fair despite uneven latency? | deep dive | server clock and process-pause hazards |
| Online Chess | 4) How do we keep the leaderboard correct and fast at 10M players? | deep dive | derived ranking with authoritative game results |
| Online Chess | Some additional deep dives you might consider | deep dive | extra transfer prompts |
| Online Chess | What is Expected at Each Level? | level expectation | calibrate transfer depth |
| Online Chess | Mid-level | level expectation | basic game flow |
| Online Chess | Senior | level expectation | correctness and scale |
| Online Chess | Staff+ | level expectation | fairness, clocks, failover, cheat boundaries |
DDIA 精确决策卡
只读能改变今天设计决定的小节。
| 项目问题 | 精确 DDIA subsection | 改变的系统决定 |
|---|---|---|
| Online Chess 为什么不能照搬聊天的 eventual ordering？ | Ch10 · 线性一致性 | 每盘棋的 move 必须像单对象线性化：同一 move number 只能有一个权威结果。 |
| 棋钟公平为什么不能相信客户端倒计时？ | Ch9 · 对同步时钟的依赖 | 客户端时钟只用于显示；超时裁决由服务器事件时间和可审计 deadline 决定。 |
本日项目 artifacts
脚本、音频、PDF 与 mock evidence 直接从对应日打开。
今日产出、修复与英语 recall
| 课程角色 | TRANSFER · blind first then live-source read |
|---|---|
| 必须交付 | Online Chess transfer memo：changed requirements、invalid reuse assumptions、new bottlenecks、shallow-transfer follow-ups。 |
| 修复规则 | 如果把棋局 move 当聊天消息队列，补 server-side legal move validation、single authoritative move number、clock裁决。 |
| English recall | English recall: “Chess moves require authoritative validation and a single accepted move order per game.” |
Detailed lecture notes, audio, recall scripts, PDFs, Staff Q&A, and mock packs are archived locally and are intentionally not published on this site.