今日固定时间表
只有三个学习窗口：08:50-10:55、14:30-16:15、20:30-21:15。section links 只放在本日页面。
| 08:50-10:55 | System design 读 Metrics Monitoring 完整 heading inventory；把 ingest/store/query/alert/notify 路径和 cardinality policy 画成一个状态/数据流。 |
|---|---|
| 14:30-16:15 | NeetCode Linked List 三道连续题位，每题 30m solve + 5m pattern/invariant/bug/complexity evidence。 |
| 20:30-21:15 | Recall / Staff Q&A / Mock 英语 recall：explain why alert reliability differs from dashboard freshness, and why consumer lag is user-visible. |
算法模块
连续 NeetCode Linked List tag；每天恰好 3 个 slot。
| # | Problem / mode | Pattern | Invariant | Bug risk | Time | Space |
|---|---|---|---|---|---|---|
| 13 | Palindrome Linked List NEW · 30m solve + 5m evidence | middle + reverse second half | compare mirrored values from head and reversed half | odd length middle handling | O(n) | O(1) |
| 14 | Intersection of Two Linked Lists NEW · 30m solve + 5m evidence | two-pointer length equalization | both pointers traverse equal total length | comparing values not node identity | O(n+m) | O(1) |
| 15 | Linked List Cycle II NEW · 30m solve + 5m evidence | Floyd entry recovery | after meeting, head and slow meet at entry | returning first meeting point | O(n) | O(1) |
Hello Interview 精确目录
保留 live original titles；每行都有 canonical anchor 和 disposition。
| 项目 | 精确 canonical section | Disposition | 今天怎么用 |
|---|---|---|---|
| Metrics Monitoring | Understanding the Problem | required reading | metrics platform surface and reliability role |
| Metrics Monitoring | Functional Requirements | required reading | ingest, dashboard queries, alert rules, notifications |
| Metrics Monitoring | Non-Functional Requirements | required reading | 5M metrics/sec, dashboard seconds, alerts under one minute, late data |
| Metrics Monitoring | The Set Up | required reading | ingest/store/query/alert strategy |
| Metrics Monitoring | Planning the Approach | required reading | build core data flow before deep dives |
| Metrics Monitoring | Defining the Core Entities | required reading | Metric, Label, Series, Alert Rule, Dashboard |
| Metrics Monitoring | Data Flow | required reading | write-heavy continuous path and bursty read path |
| Metrics Monitoring | API or System Interface | required reading | batched ingest, query DSL, alert rule API |
| Metrics Monitoring | High-Level Design | required reading | agents, Kafka, TSDB, query service, alert evaluator |
| Metrics Monitoring | 1) The platform can ingest metrics from services | required reading | agent buffering and ingestion queue |
| Metrics Monitoring | 2) Users can query and visualize metrics on dashboards | required reading | time-series storage and query service |
| Metrics Monitoring | 3) Users can define alert rules with thresholds | required reading | scheduled query evaluator baseline |
| Metrics Monitoring | 4) Users receive notifications when alerts fire | required reading | dedupe, grouping, silence, escalation |
| Metrics Monitoring | Potential Deep Dives | deep dive | dashboard latency, real-time alerts, HA, cardinality |
| Metrics Monitoring | 1) How do we serve low-latency dashboard queries over weeks of data? | deep dive | rollups, cache, query splitting |
| Metrics Monitoring | 2) How do we reduce alert latency below 1 minute? | deep dive | polling frequency versus stream alerting |
| Metrics Monitoring | 3) How do we ensure high availability during spikes and failures? | deep dive | redundancy, durable buffers, meta-monitoring |
| Metrics Monitoring | 4) How do we handle cardinality explosion? | deep dive | policy store, tracker, label allowlist, dropped-metric alert |
| Metrics Monitoring | What is Expected at Each Level? | level expectation | calibrate Senior+/Staff depth |
| Metrics Monitoring | Mid-level | level expectation | queue + TSDB + basic alerts |
| Metrics Monitoring | Senior | level expectation | cardinality, rollups, stream processing |
| Metrics Monitoring | Staff+ | level expectation | meta-monitoring, backpressure, migration, isolation |
DDIA 精确决策卡
只读 Ch8、Ch12、Ch13 中能改变今天设计选择的小节。
| 项目问题 | 精确 DDIA subsection | 改变的系统决定 |
|---|---|---|
| Monitoring consumers fall behind during incidents | Ch12 · 当消费者跟不上生产者时 | consumer lag becomes a product SLI; shed/compact lower-value metrics before alert blindness |
| Dashboards and alerts are derived views | Ch12 · 维护物化视图 | rollups and alert state are materialized from metric streams and can be rebuilt |
| Monitoring must observe its own derived state | Ch13 · 观察派生数据状态 | meta-monitor ingest lag, dropped series, rule lag, notification backlog |
| High-cardinality labels threaten integrity and timeliness | Ch13 · 及时性与完整性 | drop/limit unsafe labels with explicit counters instead of silently degrading all queries |
本日项目 artifacts
今日产出、修复与英语 recall
| 必须交付 | Metrics Monitoring CORE sheet：agent buffer, Kafka lag, TSDB, rollups, alert evaluator, notification dedupe, cardinality enforcement。 |
|---|---|
| 修复规则 | 如果回答只说组件名，重写为 decision -> mechanism -> invariant -> failure window -> recovery -> metric。 |
| English recall | Correctness is the durable source of truth; low-latency status, aggregates, dashboards, and alerts are views with freshness and repair semantics. |
Detailed lecture notes, audio, recall scripts, PDFs, Staff Q&A, and mock packs are archived locally and are intentionally not published on this site.