🏗️ 系统设计 / System Design — Day 49

设计协同编辑器 / Design a Collaborative Editor (Google Docs)

⏱️ 预计阅读时间 / Est. read time: 3 min | 难度 / Difficulty: Expert

想象你在设计... / The Scenario

想象你在设计 Google Docs：两个人同时编辑同一份文档，双方的更改应该实时同步，不能覆盖对方的内容。

Imagine you're building Google Docs: two users editing the same doc simultaneously, changes must sync in real time without overwriting each other.

这是分布式系统里最难的问题之一——并发冲突解决。

This is one of the hardest distributed systems problems: concurrent conflict resolution.

核心挑战 / Core Challenge: Operational Transformation vs CRDT

协同编辑的本质问题：用户 A 和用户 B 同时操作同一文档，服务器收到两个冲突的变更，怎么合并？

The core problem: Users A and B make concurrent changes, server receives two conflicting ops. How to merge?

两种主流方案 / Two Main Approaches:

方案	OT (Operational Transformation)	CRDT (Conflict-free Replicated Data Type)
代表	Google Docs	Figma, Linear, Notion
原理	变换操作以适应其他操作	数学上保证自动合并
复杂度	实现复杂，服务器有序	实现较简单，去中心化

架构图 / Architecture

Client A Server Client B │ │ │ │──Op: insert("H",0)─────>│ │ │ │──Op: insert("H",0)─────>│ │<────────────────────────│<──Op: insert("W",0)─────│ │ │ │ │ [OT Engine] │ │ transform ops │ │ → final order │ │ │ │ │<──broadcast final op────│──broadcast final op────>│ ┌─────────────────────────────────────────────────────┐ │ Architecture │ │ │ │ WebSocket Gateway ──► Op Queue (Kafka) │ │ │ │ │ │ Presence Service OT/CRDT Engine │ │ (who's editing) │ │ │ Document Store │ │ (PostgreSQL + snapshots) │ │ │ │ │ Version History │ │ (immutable log) │ └─────────────────────────────────────────────────────┘

关键设计决策 / Key Design Decisions

1. OT 的工作原理

初始状态: "HELLO" 用户A: delete(0, 1) → "ELLO" 用户B: insert("!", 5) → "HELLO!" 同时到达服务器，需要 transform: A 先执行: "ELLO" B 的 insert(5) → transform → insert(4): "ELLO!" ✅

2. 文档存储策略

不存最终状态，而是存操作日志 (operation log)
定期生成快照 (checkpoint)，加速重建
版本 = (clientId, clock) — 逻辑时钟，非物理时间

3. 实时传输: WebSocket

HTTP 轮询延迟太高，Server-Sent Events 单向
WebSocket 双向，持久连接，适合协作场景

为什么这样设计 / Why This Design?

OT vs CRDT 选择：

Google Docs 用 OT，需要中央服务器做变换 — 简化客户端逻辑
CRDT 允许离线操作后合并 — Figma 和 Linear 用它，支持离线/弱网

操作日志 vs 状态快照：

存操作日志 = 完整历史，可以实现"任意版本回滚"
只存最新状态会丢失协作上下文

别踩这个坑 / Common Mistakes

❌ 用时间戳排序并发操作 — 分布式系统时钟不可靠，两台机器的"同时"可能差几百毫秒

✅ 用逻辑时钟 / Lamport Clock 或向量时钟建立因果顺序

❌ 直接用数据库乐观锁 — "最后写入者获胜"(LWW) 会丢失数据

✅ OT 或 CRDT，确保所有操作都被保留并正确合并

📚 References

🧒 ELI5

两个人同时改同一个 Google Doc，就像两个人同时在一张纸上写字。OT 就像一个裁判，看到两个人都写了东西，想办法把两份更改都保存下来，谁的也不丢。

Two people editing the same doc is like two people writing on the same piece of paper at once. OT is like a referee who sees both changes and figures out how to keep both without losing either.

💻 算法 / Algorithms — Day 50

#100 Same Tree — Easy 🟢 | Trees Pattern (5/15)

⏱️ 预计阅读时间 / Est. read time: 4 min

🧩 Trees 模式 (5/15) — 复用 Day 54 引入的树遍历模板

Building on the 树遍历模式 template from the start of this block.

模版回顾 / Template Recap:

def dfs(node):
    if not node: return BASE_CASE
    left = dfs(node.left)
    right = dfs(node.right)
    return COMBINE(node.val, left, right)

🔗 Links

LeetCode: https://leetcode.com/problems/same-tree/ 🟢
NeetCode: https://www.youtube.com/watch?v=vRbbcKXCxOw

真实场景类比 / Real-World Analogy

你在做文件系统差异比较 (diff)：两棵目录树是否完全相同？每个节点（文件/文件夹）的名字、位置都必须一样。

You're doing a file system diff: are two directory trees exactly identical? Every node's name and position must match.

问题分析 / Problem

给定两棵二叉树，判断它们是否结构相同且节点值相同。

Given two binary trees, determine if they are structurally identical and nodes have the same values.

1 1 / \ / \ 2 3 2 3 p = q → True 1 1 / \ 2 2 p ≠ q → False

映射到模版 / Map to Template

这道题是双树同步 DFS — 模板的自然扩展：

BASE_CASE: 两个都是 None → True; 一个是 None → False COMBINE: node values 相等 AND 左子树相同 AND 右子树相同

Python 解法 / Solution

class TreeNode:
    def __init__(self, val=0, left=None, right=None):
        self.val = val
        self.left = left
        self.right = right

def isSameTree(p: TreeNode, q: TreeNode) -> bool:
    # BASE CASE: both None → structurally equal at this position
    if not p and not q:
        return True
    # one is None, other isn't → mismatch
    if not p or not q:
        return False
    # COMBINE: values must match AND both subtrees must match
    return (p.val == q.val and
            isSameTree(p.left, q.left) and
            isSameTree(p.right, q.right))

# Trace example:
#       1             1
#      / \           / \
#     2   3         2   3
#
# isSameTree(1, 1):
#   1 == 1 ✓
#   isSameTree(2, 2):
#     2 == 2 ✓, isSameTree(None,None)=True, isSameTree(None,None)=True → True
#   isSameTree(3, 3):
#     3 == 3 ✓, ... → True
#   → True ✅

时间复杂度 / Complexity: O(n) time, O(h) space where h = tree height

这道题 vs 同系列 / Variation from Block

问题	关键变化	模版调整
#226 Invert Binary Tree	改变结构	COMBINE 交换左右子树
#104 Max Depth	返回数值	COMBINE 取 max
#110 Balanced	返回高度+是否平衡	COMBINE 返回元组
#100 Same Tree	双树同步	参数变成两个节点
#572 Subtree of Another Tree (下一题)	包含关系	isSameTree + 递归检查

注意：下一题 #572 直接调用这道题的函数！学好这道，下道题轻松解。

Note: #572 literally calls isSameTree as a helper! Master this and the next problem is easy.

举一反三 / Pattern Connections

双指针 DFS 模式 — 两棵树同步遍历：

#100 Same Tree → 完全相同
#572 Subtree → 包含关系
#951 Flip Equivalent → 镜像等价
#1367 Linked List in Binary Tree → 链表在树中

📚 References

🧒 ELI5

判断两棵树是否一样，就像比对两张照片：先看根节点的脸，再看左手，再看右手。每个部位都一样，才算相同。

Checking if two trees are the same is like comparing two photos side by side: check the root's face, then left arm, then right arm. Every part must match.

🗣️ 软技能 / Soft Skills — Day 49

为不可见的工程投资发声 / Advocating for Invisible Engineering Work

⏱️ 预计阅读时间 / Est. read time: 2 min | Level: Staff

面试题 / The Question

"Tell me about a time you had to advocate for engineering investment that wasn't user-visible."

"请讲一个你为不可见的工程投资（如基础设施、技术债务、工具改进）争取资源的经历。"

为什么这道题重要 / Why This Matters

Staff+ 工程师的核心价值之一：看见别人看不见的问题，并说服他人投资解决它。

用户不会因为你的部署速度快 3 倍而给你发邮件夸你。但如果你不做这件事，6 个月后团队速度会死。

One of the core Staff+ skills: seeing invisible problems and convincing others to invest. Users won't thank you for faster deploys — but if you don't do it, the team dies in 6 months.

STAR 拆解 / STAR Breakdown

Situation（情境）

描述系统的隐性问题：测试慢、CI 不稳定、数据库缺少索引...
说明为什么没人关注它：产品压力、短期优先
"我们的 CI pipeline 平均需要 45 分钟，每天每个工程师浪费 1-2 小时等待。"

Task（任务）

你的目标：让领导相信这值得投资
挑战：没有用户可见的功能交付，ROI 不直观

Action（行动）

量化隐性成本：45 min × 8 engineers × 5 days = 30 engineer-hours/week
建立 before/after 对比：跑 POC，证明方案可行
用业务语言讲：不说"CI 慢"，说"每季度 390 小时工程师时间浪费"
降低感知风险：提议先做一个 sprint 的试验，可测量

Result（结果）

争取到了 1 sprint 投资 → CI 时间从 45 min 降到 8 min
团队速度提升，加速了未来几个月的功能交付

❌ 差答案 vs ✅ 好答案

❌ "我说服了领导，告诉他们技术债很重要。"

→ 没有量化，没有业务语言，听起来像抱怨。

✅ "我做了一个数据分析，发现 CI 瓶颈每季度造成 390 小时的工程损耗。我做了一个 POC 把时间从 45 分钟降到了 8 分钟，然后用这个 demo 加上 ROI 数据获得了一个 sprint 的投资。"

→ 量化问题 → 证明方案 → 用商业语言 → 争取到资源

Senior/Staff 差异 / Senior vs Staff Tips

Senior 思路：发现问题，解决问题，向团队汇报。

Staff 思路：

将技术问题翻译为商业影响 (business impact)
主动建立可测量的 KPI 来追踪投资回报
识别力量乘数 (force multipliers)：一次投资，N 倍长期收益
让这个工作可见：写 doc，做 demo，在 all-hands 上分享

Key Takeaways

量化隐性成本 — 工程时间、事故频率、部署频率都可以换算成 $
POC 先行 — 证明可行性比光讲道理有力 10 倍
用业务语言 — PM 和 EM 关心的是速度和成本，不是技术细节
降低风险感知 — 提议"一个 sprint 试验"比"重构三个月"更容易被批

📚 References

🧒 ELI5

这就像你发现家里水管老化了，但没人注意。你去计算"如果水管爆了要花多少修理费"，做个小测试证明换管子不贵，然后用这些数据说服家里人现在就换。

It's like discovering the house pipes are old but nobody notices. You calculate "what if they burst?" costs, do a small test to prove fixing it is cheap, then use that data to convince your family to fix it now.

🤖 AI — Day 59

AI 新闻速递 / AI News Roundup

⏱️ 预计阅读时间 / Est. read time: 2 min | 本周最热 / This Week's Highlights

📡 本周 AI 大事 / This Week in AI

1. 🏢 微软 Build 2026: MAI 模型家族发布

Microsoft launches 7 MAI models at Build 2026

微软在 Build 2026 (6月2日) 发布了七款自研 AI 模型，宣告战略转向"长期自给自足"。

Microsoft unveiled seven in-house AI models at Build 2026 (June 2), signaling a strategic pivot toward "long-term self-sufficiency" in AI.

亮点 / Highlights:

MAI-Thinking-1: 旗舰推理模型，35B 参数，256K 上下文窗口，从头训练，使用商业授权数据。Microsoft's flagship reasoning model — 35B active parameters, 256K context window, trained on commercially licensed data.
MAI-Code-1-Flash: 5B 参数的代码模型，深度集成 GitHub Copilot 和 VS Code。5B parameter coding model, deeply integrated into GitHub Copilot and VS Code.
Frontier Tuning: 企业可用 RL 在自有工作流上定制 MAI 模型，据报道微软内部 Excel 场景下定制模型媲美 GPT-5.4，效率提升约 10 倍。Enterprise-grade RL-based tuning on custom workflows — reportedly matches GPT-5.4 for Excel use cases at ~10× efficiency.

🔗 来源 / Source: https://microsoft.ai/news/building-a-hillclimbing-machine-launching-seven-new-mai-models/

2. 🔵 GPT-5.5 成为 ChatGPT 默认模型

GPT-5.5 Instant becomes ChatGPT's default

OpenAI 推出 GPT-5.5 系列，包含 Pro 和 Instant 变体。GPT-5.5 Instant 据报道已在 6 月成为 ChatGPT 默认模型，主打企业知识工作和编程场景的强化 Agent 能力。

OpenAI released the GPT-5.5 family with Pro and Instant variants. GPT-5.5 Instant reportedly became the default ChatGPT model in June, with enhanced agentic capabilities for enterprise knowledge work and coding.

🔗 来源 / Source: https://augusto.digital/insights/blogs/monthly-llm-news-june-2026/

3. ✨ Google Gemini 3.5 Flash 正式 GA

Gemini 3.5 Flash goes generally available

Google 的 Gemini 3.5 Flash 于 5 月 19 日 GA，成为 Gemini 应用和 AI Search 的默认模型。据报道在编程和 Agent 基准测试上超越 Gemini 3.1 Pro，速度是上一代旗舰的 4 倍。

Google's Gemini 3.5 Flash became GA on May 19, now the default in the Gemini app and AI Mode in Search. Reportedly outperforms Gemini 3.1 Pro on coding and agentic benchmarks at 4× the speed of previous flagship.

🔗 来源 / Source: https://blog.mean.ceo/new-ai-model-releases-news-june-2026/

🔍 工程师视角 / Engineer's Take

这一周的核心主题：垂直整合 vs 平台开放

The week's theme: vertical integration vs. open platforms

微软 MAI = 自建模型 + 深度产品整合（Office, GitHub）
OpenAI/Google = 开放 API，生态优先

对你的影响 / What this means for you:

MAI-Code-1-Flash 值得关注 — 5B 参数但深度 IDE 集成，可能比大模型更实用
Frontier Tuning 让企业用自己的数据精调模型成为主流，RAG 之外的新路径
模型战争打到了"效率"维度，不只是"最强"了

📚 References

🧒 ELI5

微软这周说"我要自己造玩具，不靠别人了"，发布了一堆自家 AI 模型。Google 也发了更快的新模型，OpenAI 把更新的模型设为了默认。大家都在比谁更聪明、更快、更便宜。

Microsoft this week said "I'll make my own toys," launching their own AI model family. Google also dropped a faster new model, and OpenAI made their newer model the default. Everyone's racing to be smarter, faster, and cheaper.

Friday, June 5, 2026

🏗️ 系统设计 / System Design — Day 49

设计协同编辑器 / Design a Collaborative Editor (Google Docs)

想象你在设计... / The Scenario

核心挑战 / Core Challenge: Operational Transformation vs CRDT

架构图 / Architecture

关键设计决策 / Key Design Decisions

1. OT 的工作原理

2. 文档存储策略

3. 实时传输: WebSocket

为什么这样设计 / Why This Design?

别踩这个坑 / Common Mistakes

📚 References

🧒 ELI5

💻 算法 / Algorithms — Day 50

#100 Same Tree — Easy 🟢 | Trees Pattern (5/15)

🔗 Links

真实场景类比 / Real-World Analogy

问题分析 / Problem

映射到模版 / Map to Template

Python 解法 / Solution

这道题 vs 同系列 / Variation from Block

举一反三 / Pattern Connections

📚 References

🧒 ELI5

🗣️ 软技能 / Soft Skills — Day 49

为不可见的工程投资发声 / Advocating for Invisible Engineering Work

面试题 / The Question

为什么这道题重要 / Why This Matters

STAR 拆解 / STAR Breakdown

❌ 差答案 vs ✅ 好答案

Senior/Staff 差异 / Senior vs Staff Tips

Key Takeaways

📚 References

🧒 ELI5

🤖 AI — Day 59

AI 新闻速递 / AI News Roundup

📡 本周 AI 大事 / This Week in AI

1. 🏢 微软 Build 2026: MAI 模型家族发布

2. 🔵 GPT-5.5 成为 ChatGPT 默认模型

3. ✨ Google Gemini 3.5 Flash 正式 GA

🔍 工程师视角 / Engineer's Take

📚 References

🧒 ELI5