01 · LEDGER
Money movement before status
Payment 先保护 ledger/idempotency/reconciliation，再追求低延迟 status/webhook。
WEEK 06 · 2026.08.31-09.06 · WRITER GATE
Ledger Truth, Stream Truth, Monitoring Truth
Payment System、Ad Click Aggregator、Metrics Monitoring 三个 CORE 项目共同训练：正确性来自可审计事实、幂等与重放；低延迟 dashboard/status 只是派生视图。
能力主线
Week 6 的关键词不是 realtime，而是 truth: 钱、点击和监控样本分别由什么事实来证明，派生视图怎样修复。
02 · STREAM
Raw event before aggregate
Ad Click 用 raw stream/lake 证明正确性；one-minute aggregate 是可修正 view。
03 · OBSERVABILITY
Series policy before dashboard
Metrics Monitoring 用 cardinality/backpressure/alert SLIs 保护可见性。
项目角色
周级 overview 只放项目首页链接；所有 source section anchors 放在 daily pages。
CORE · 24 canonical headings
Payment System
ledger truth, idempotency, reconciliation, compensation
CORE · 24 canonical headings
Ad Click Aggregator
at-least-once click aggregation, event time, dedupe, Lambda reconciliation
CORE · 22 canonical headings
Metrics Monitoring
time-series ingestion, alert windows, cardinality, backpressure
DDIA 决策地图（无地毯式阅读）
这里只列 subsection 名称；具体 anchor URL 在 day 页面校验。
| 日 | 项目问题 | DDIA subsection | 改变的决定 |
|---|---|---|---|
| Day 1 | Payment timeout/retry cannot double-charge a customer | Ch8 · ACID 的含义 | ledger state transition is transactional; card-network uncertainty stays pending |
| Day 1 | Payment API retry needs effect-once semantics | Ch8 · 恰好一次消息处理 | store idempotency key with the state transition; broker exactly-once is not the proof |
| Day 2 | Should payment service use 2PC across DB, Kafka, provider? | Ch8 · 分布式事务 | avoid heterogenous 2PC for external networks; use outbox/CDC and reconciliation |
| Day 2 | What if completion event is missing after DB commit? | Ch8 · 再谈恰好一次消息处理 | replay durable state and processed-event IDs instead of trusting a single publish |
| Day 2 | How does the ledger prove a six-month-old dispute? | Ch13 · 为可审计性而设计 | append immutable entries and make corrections as compensating events |
| Day 3 | Click stream needs durable low-latency ingestion | Ch12 · 传递事件流 | Kafka/Kinesis is a durable stream buffer, not the aggregate truth |
| Day 3 | One-minute click buckets must use event time | Ch12 · 事件时间与处理时间 | window by click/impression event time; expose processing lag separately |
| Day 3 | Metric windows need explicit bucket semantics | Ch12 · 窗口的类型 | tumbling one-minute buckets for advertiser reports; late corrections carry version/as-of |
| Day 4 | Duplicate click across minute boundary must not count twice | Ch12 · 幂等性 | signed impression ID is deduped before the stream and reconciled later |
| Day 4 | Flink state or consumer dies during aggregation | Ch12 · 失败后重建状态 | replay retained raw events and restore dedupe/aggregate state |
| Day 4 | Late events and bad deploy corrupt real-time views | Ch12 · 处理滞留事件 | admit lateness policy plus batch true-up; do not call the speed layer final |
| Day 4 | Batch layer must repair speed-layer mistakes | Ch13 · 应用演化后重新处理数据 | raw event lake enables reprocessing after schema/code fixes |
| Day 5 | Monitoring consumers fall behind during incidents | Ch12 · 当消费者跟不上生产者时 | consumer lag becomes a product SLI; shed/compact lower-value metrics before alert blindness |
| Day 5 | Dashboards and alerts are derived views | Ch12 · 维护物化视图 | rollups and alert state are materialized from metric streams and can be rebuilt |
| Day 5 | Monitoring must observe its own derived state | Ch13 · 观察派生数据状态 | meta-monitor ingest lag, dropped series, rule lag, notification backlog |
| Day 5 | High-cardinality labels threaten integrity and timeliness | Ch13 · 及时性与完整性 | drop/limit unsafe labels with explicit counters instead of silently degrading all queries |
| Day 6 | Three mocks must separate correctness from fresh views | Ch13 · 数据库的端到端原则 | end-to-end idempotency and reconciliation live above individual storage/stream tools |
| Day 7 | Final synthesis must verify derived views | Ch13 · 数据流系统的正确性 | low-latency views are trusted only when validated against durable source events |
| Day 7 | Repair loop must catch software bugs and bad promises | Ch13 · 信任但验证 | use reconciliation, audits, and invariant metrics as the weekly proof |
固定时间合同
| 时间 | Week 6 不变量 | 证据 |
|---|---|---|
| 08:50-10:55 | 系统设计主块，先闭卷再精读。 | 每天一个 bounded output。 |
| 14:30-16:15 | NeetCode Linked List，连续单一 tag，每天 3 题。 | 21 个 data-neetcode-slot。 |
| 20:30-21:15 | recall / Q&A / mock / repair。 | scorecard 记录。 |
7 天执行
2026-08-31 · MON
Payment System：PaymentIntent、ledger truth 与 idempotent charge HLD
先把支付系统讲成状态机和账本事实：API 超时只代表未知，不能代表失败。
进入2026-09-01 · TUE
Payment System：immutable ledger、reconciliation、compensation 与 webhook safety
把 payment network 的不确定性收进 pending + reconciliation，不用 timeout 猜钱是否移动。
进入2026-09-02 · WED
Ad Click Aggregator：server-side redirect、event time 与 one-minute aggregate HLD
先把低延迟 view 和正确 raw click stream 拆开；广告主看到的是聚合视图，不是事实来源。
进入2026-09-03 · THU
Ad Click Aggregator：at-least-once aggregation、late events、dedupe state 与 reconciliation
不幻想 exactly-once；用 signed impression ID、dedupe cache、raw lake replay 和 batch true-up 把错误变成可修复。
进入2026-09-04 · FRI
Metrics Monitoring：series model、alert windows、cardinality 与 backpressure
监控系统不是所有点都永久保存；它要在看得见、告得准、扛得住之间做明确取舍。
进入2026-09-05 · SAT
三场 CORE mock：Payment、Ad Click、Metrics 各 45 分钟 + 两个 deep dives
今天只做选择驱动 mock：每场都必须追问候选人已经承诺的 source of truth、failure window 和 metric。
进入2026-09-06 · SUN
Week 6 synthesis：修复最弱回答，收敛 source/link/artifact/visual gate
只修 Week 6：把 ledger、aggregation、monitoring 三种 derived view 的共同不变量压成可复述答案。
进入Applied AI radar 决策
INTENTIONAL OMISSION
不安排 frontier AI reading
本周没有一手/原作者 AI source 会改变 payment ledger、click aggregation 或 metrics monitoring 的具体 contract、failure model、security boundary、evaluation plan 或 operating model。记录为 intentional omission，不用泛化 AI 阅读占用窗口。
ACCEPTED SOURCES
Hello Interview + DDIA2 exact decisions
证据来自三个 live Hello Interview canonical inventories，以及 DDIA2 Ch8/Ch12/Ch13 的精确决策小节。
Detailed lecture notes, audio, recall scripts, PDFs, Staff Q&A, and mock packs are archived locally and are intentionally not published on this site.