System Design Synthesis — Day 89: Read Path vs. Write Path Optimization

🏗️ 系统设计综合 / System Design Synthesis

专题: 读路径 vs 写路径优化 — 如何为不同访问模式设计不同的架构

Topic: Read Path vs. Write Path Optimization — Designing Different Architectures for Different Access Patterns

想象你在 Meta 担任系统设计面试官 / Imagine You're a System Design Interviewer at Meta

被面试者给出一个看似合理的设计：一个数据库，所有读写都走同一路径。你会问什么？

A candidate gives you a seemingly reasonable design: one database, all reads and writes go through the same path. What do you ask?

"你的读写比是多少？为什么读和写要用同一个代码路径？"

"What's your read-to-write ratio? Why do reads and writes share the same code path?"

核心洞察：读写路径天生就不同 / Core Insight: Read & Write Paths Are Fundamentally Different

真实架构对比 / Real Architecture Comparison

案例 1: Twitter/X 的 Fanout 演化

• 早期: 写入时 fanout (写路径重)，每条 tweet 写入所有 follower 的 timeline
• 问题: 名人用户 (Lady Gaga) 写一条推文 → 1亿次写入
• 解法: 混合模式 — 普通用户写入 fanout，名人用户读取时 merge
• 教训: 写路径优化 ≠ 读路径简单，需要针对访问模式拆分

案例 2: Facebook TAO (The Associations and Objects)

• 读路径: 多层缓存 (L1 local + L2 regional) → 99%+ hit rate
• 写路径: 单 leader 写入 MySQL → 异步复制到 cache
• 关键: 读写完全解耦，读路径不感知底层存储

案例 3: Kafka 作为写路径的 Buffer

• 写路径: Producer → Kafka → Consumer (异步，append-only)
• 读路径: 预计算结果存入 Redis/Elasticsearch 供查询
• CQRS (Command Query Responsibility Segregation) 的极致体现

架构图 / Architecture

什么时候分离读写路径？/ When to Separate Read/Write Paths?

✅ 必须分离 / Must separate:

• 读写比 > 10:1 (大多数 CRUD 应用)
• 读延迟 SLA < 10ms 但写可以接受 100ms
• 需要不同的一致性保证 (最终一致 vs 强一致)

⚠️ 可以不分离 / Can skip:

• 小型服务 (<1K QPS)
• 强一致性是硬需求 (金融交易)
• 团队规模小，复杂度成本高过收益

常见的坑 / Common Mistakes

❌ 对所有查询都用主库 → 浪费 read replica 资源，主库成瓶颈

❌ 缓存失效逻辑在写路径 → 难以维护，容易造成不一致

❌ 忽略复制延迟 → 读到过时数据导致用户困惑 (刚刚发的帖子看不到)

✅ 最佳实践: 写后读 (read-after-write consistency) 用 session token 或 version 号

📚 References

• Facebook TAO: The Power of the Graph — USENIX ATC 2013
• Twitter's Fanout Service Evolution — Twitter Engineering Blog
• CQRS Pattern — Martin Fowler
• Designing Data-Intensive Applications, Chapter 5 — Martin Kleppmann

🧒 ELI5

想象餐厅里有两条通道：一条是厨房的"出菜口"（读），另一条是"点餐台"（写）。如果每次有人点单，厨师都要停下来处理，出菜就慢了。把两条通道分开，厨师专心做菜，收银员专心收单，效率翻倍。

Imagine a restaurant with two lanes: one for food pickup (read), one for order taking (write). If the chef had to stop cooking every time someone placed an order, meals would be slow. Separate the lanes — chef cooks, cashier takes orders — double the throughput.

Algorithms — Day 89: #39 Combination Sum (Medium) — Backtracking

💻 算法 / Algorithms

#39 Combination Sum — Medium 🟡

🧩 回溯模式 (2/9) — building on the template from Day 88 (Subsets)

🔗 LeetCode #39 | 📹 NeetCode Solution

这道题是模板的哪种变体？/ How Does This Vary from the Subsets Template?

上次 Subsets (#78) 是枚举所有可能的选择子集，没有约束。

这次 Combination Sum 加了一个约束：子集元素之和 = target，而且元素可以重复使用。

Last time (Subsets #78), we enumerated all possible subsets with no constraint. This time, there's a constraint: subset must sum to target, and elements can be reused (unlimited times).

两个关键变化 / Two Key Differences:

1. 停止条件变了: sum == target (不再是遍历到末尾)
2. 剪枝新增: sum > target 时直接 return
3. 重复使用: 递归时起点不后移 (start 而非 start + 1)

真实场景 / Real-World Analogy

想象你在收银台，手里有 [2, 3, 6, 7] 面值的硬币（可以重复用），需要凑出恰好 7 元。

回溯法就是把所有"试着凑"的过程系统化：选一枚，继续凑，凑不上去就退回来换一枚。

Imagine you have coins of denominations [2, 3, 6, 7] (unlimited supply) and need to make exactly $7. Backtracking systematically tries every combination: pick one, keep going, backtrack when over.

模板对比 / Mapping to Template

# 通用模版回顾 / General Template Recap
def backtrack(path, choices):
    if IS_COMPLETE(path):       # ← 这里变了: sum(path) == target
        result.append(path[:])
        return
    for choice in choices:
        if IS_VALID(choice):    # ← 这里加了: sum(path) + choice <= target
            path.append(choice)
            backtrack(path, NEXT_CHOICES)  # ← 这里变了: 起点不后移
            path.pop()

Python Solution (with trace)

def combinationSum(candidates: list[int], target: int) -> list[list[int]]:
    result = []
    candidates.sort()  # sort for early termination (pruning)

    def backtrack(start: int, path: list[int], remaining: int):
        # Base case: found valid combination
        if remaining == 0:
            result.append(path[:])  # shallow copy of current path
            return

        for i in range(start, len(candidates)):
            num = candidates[i]

            # Pruning: since sorted, if this candidate exceeds remaining,
            # all subsequent ones will too — stop early
            if num > remaining:
                break

            path.append(num)
            backtrack(i, path, remaining - num)  # i not i+1: allow reuse!
            path.pop()  # undo choice

    backtrack(0, [], target)
    return result

# Trace: candidates=[2,3,6,7], target=7
# backtrack(0, [], 7)
#   pick 2 → backtrack(0, [2], 5)
#     pick 2 → backtrack(0, [2,2], 3)
#       pick 2 → backtrack(0, [2,2,2], 1)
#         pick 2 → remaining -1 < 0, break
#         pick 3 → remaining -2 < 0, break
#       pop 2 → [2,2]
#       pick 3 → backtrack(1, [2,2,3], 0) → ✅ append [2,2,3]
#       pop 3 → [2,2]
#     pop 2 → [2]
#     pick 3 → backtrack(1, [2,3], 2)
#       pick 3 → remaining -1 < 0, break
#     ...
#   pick 7 → backtrack(3, [7], 0) → ✅ append [7]

Complexity

• Time: O(n^(T/M)) where T = target, M = min candidate value — branching factor
• Space: O(T/M) — max recursion depth is target/minimum (for deepest combination)
• Pruning via sort + break drastically reduces actual nodes visited

举一反三 / Connect to Pattern Block

关键规律 / Key Rule:

• 不需要排列顺序 (combination) → for i in range(start, n) 保证不重复
• 需要排列顺序 (permutation) → for i in range(0, n) + visited array

📚 References

• LeetCode #39 Combination Sum
• NeetCode Video — Combination Sum
• Backtracking Explained — Back To Back SWE

🧒 ELI5

想象你在玩拼图，每块拼图可以反复用。你的目标是拼出"高度为7"的塔。你一块一块地叠，叠过头了就退一步换一块。这就是回溯——系统地试，不对就退，直到找到所有答案。

Imagine building a tower of height 7 using blocks of various sizes (reusable). You stack blocks one by one; if too tall, remove the last block and try a different one. That's backtracking — systematic trial and undo.

Soft Skills Synthesis — Day 89: The Staff Engineer's Dilemma

🗣️ 软技能综合 / Soft Skills Synthesis

专题: Staff 工程师的两难困境 — 技术深度 vs. 广度影响力

Topic: The Staff Engineer's Dilemma — Technical Depth vs. Broad Influence

面试题 / Interview Prompt

"You're a Staff Engineer. You could spend the next quarter either: (A) diving deep on a critical performance problem that only you can solve, or (B) helping 5 other teams unblock architectural decisions. Both are valuable. How do you decide? What have you done in practice?"

你是一名 Staff 工程师。你可以选择：(A) 深入解决一个只有你能解决的关键性能问题，或 (B) 帮助5个团队解决架构障碍。两者都有价值。你如何决策？实际中你是怎么做的？

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

Staff+ 角色的核心张力：个人贡献者 (IC) vs. 乘数效应 (Multiplier)。

大多数候选人有很好的深度故事，但面试官想看的是：你是否理解自己在组织中的杠杆点。

The core tension of Staff+ roles: individual contributor vs. force multiplier. Most candidates have great depth stories, but interviewers want to see if you understand your leverage point in the org.

STAR 框架 / STAR Breakdown

情境 / Situation:

"我在一家增长期公司担任 Staff 工程师，负责基础架构平台团队。Q2 末，我们有一个关键的数据库连接池问题（只有我对这套遗留系统足够熟悉），同时5个产品团队正等待我评审他们的服务拆分方案。"

任务 / Task:

"我需要决定如何分配接下来6周的时间，同时不让任何一边严重受阻。"

行动 / Action:

"我做了三件事：

1. 评估不对称性：性能问题的 P95 延迟是 800ms，但不影响核心转化路径。我估算5个团队被阻塞的总工程师·周 ≈ 40人周。数字说话。
2. 降低深度工作的机会成本：我花了1天写了一份诊断文档，把我对遗留系统的知识外化，让另一名高级工程师可以接手70%的工作。
3. 批量解决架构评审：我把5个团队的评审合并成2次跨团队工作坊，同步输出设计原则文档，而不是5次单独评审。"

结果 / Result:

"架构评审在3周内完成，解放了约38人周的工程产能。性能问题由高级工程师主导，我 review 关键节点，4周后解决。我在两件事上都没有成为瓶颈。"

❌ 常见错误回答 / Common Bad Answers

❌ "我会两件都做" — 没有展示优先级判断力

❌ "个人深度贡献更重要，影响力是管理者的事" — 误解 Staff 级别的期望

❌ "我会让团队等我" — 不具备乘数思维

✅ 优秀回答的信号 / Signals of a Strong Answer

✅ 量化杠杆: 能计算出哪条路径的总影响更大

✅ 知识转移: 主动减少"只有你能做"的工作（避免成为单点故障）

✅ 批量效率: 找到能同时服务多个受众的工作方式（文档、工作坊、ADR）

✅ 时间感: 区分"紧急"和"重要"，理解延迟成本

Senior vs. Staff 的边界 / Senior vs. Staff Boundary

📚 References

• Staff Engineer: Leadership Beyond the Management Track — Will Larson
• The Engineering Executive's Primer — Will Larson
• Brag Documents: Get Credit for Your Work — Julia Evans

🧒 ELI5

想象你是学校里最会数学的人。你可以自己解100道题，也可以花时间教10个同学，让他们每人解10道题——结果一样，但你的时间更有价值了。Staff 工程师选的往往是"教"，而不是"自己全解"。

Imagine you're the best math student. You could solve 100 problems yourself, or spend time teaching 10 classmates — each then solves 10. Same output, but your time is more leveraged. Staff engineers often choose "teach" over "do it all myself."

AI News Roundup

Day 89 — AI News | 2026-07-13

🤖 AI 新闻速递 / AI News Roundup

本期新闻来源于本周网络搜索结果，所有具体数据均来自已验证来源。

All stories sourced from web searches conducted this week. Figures only from verified sources.

📰 Story 1: OpenAI 发布 GPT-5.6 — Sol / Terra / Luna 三档模型

OpenAI Releases GPT-5.6 in Three Tiers: Sol, Terra, Luna

来源 / Source: SpaceDaily | AI Intelligence Briefing

OpenAI 于 7 月 9 日公开发布了迄今最强的系统 GPT-5.6，分为三档：

• Sol — 旗舰模型，面向前沿推理和长周期 agentic 任务；带 "ultra mode"，把复杂任务分解到并行子代理（subagents）执行。
• Terra — 性能接近 GPT-5.5，但成本约为其一半。
• Luna — 最便宜最快，面向高吞吐、低延迟场景。

同时发布 ChatGPT Work —— 一个"做完整份工作"而非仅回答问题的 agent。

On July 9, OpenAI launched GPT-5.6 in three tiers — Sol (frontier reasoning + long-horizon agentic work, with an "ultra mode" that decomposes tasks across parallel subagents), Terra (near GPT-5.5 performance at ~half the cost), and Luna (cheapest/fastest for high-volume, low-latency). Alongside it: ChatGPT Work, an agent built to carry out entire jobs.

对工程师的意义 / Engineering Takeaway:

"ultra mode" 的并行子代理架构，正是我们在系统设计里讲的 fan-out / scatter-gather 模式落到 LLM 推理层——把一个大任务拆成可并行的子任务再聚合，用延迟换质量。

The subagent fan-out is the classic scatter-gather pattern applied to LLM inference — decompose, run in parallel, merge. Trade latency for answer quality.

📰 Story 2: Anthropic 年化营收突破 $30B，反超 OpenAI

Anthropic's Annualized Revenue Crosses $30B, Overtaking OpenAI

来源 / Source: AI Central | ReleaseBot: Anthropic

Anthropic 年化营收本月突破 $300 亿，比 OpenAI 高出近 $60 亿——这一反转归功于其企业市场的专注：采购合同、API 扩张、以及为企业工作流训练的 Claude。

产品侧：

• Claude Sonnet 5 在 Microsoft Foundry (Azure) 全面可用，企业可直接用已有的 Azure 消费额度部署。
• Claude Cowork 扩展到 web 和移动端，跨设备同步会话与文件，新增 Microsoft 365 写入工具（起草邮件、管理日历、创建/更新 OneDrive & SharePoint 文件）。
• Claude Code 新增内置桌面浏览器、改进的 /doctor 检查、以及 auto mode 安全增强。

Anthropic's annualized revenue crossed $30B, roughly $6B ahead of OpenAI, driven by its enterprise focus. Claude Sonnet 5 went GA on Microsoft Foundry (Azure); Claude Cowork expanded to web/mobile with Microsoft 365 write tools; Claude Code added a built-in desktop browser, improved /doctor, and auto-mode safety upgrades.

对工程师的意义 / Engineering Takeaway:

企业采购 + 云市场分发（Azure/Bedrock/Vertex）正在成为 AI 收入的主战场。"模型好"已不是壁垒，部署摩擦最小化（用现有云额度、审计日志、admin 控制）才是。

The moat is shifting from raw model quality to deployment friction — existing cloud commits, audit logs, admin controls. Distribution beats benchmarks.

📰 Story 3: Google Gemini 3.5 Pro 延期发布至 7 月

Google's Gemini 3.5 Pro Slips to July

来源 / Source: AI Landscape July 2026

原定 6 月发布的 Gemini 3.5 Pro 推迟到 7 月——企业测试者在推理和代码生成性能上发现了问题，Google 选择推迟而非硬发。

与此同时，Google 正与 OpenAI、Anthropic 就一个自愿框架展开谈判：面向美国政府的前沿模型发布与早期安全测试流程（建立在 6 月的行政令基础上）。

Gemini 3.5 Pro, promised for June, slipped to July after enterprise testers flagged reasoning and code-generation issues. Meanwhile Google, OpenAI, and Anthropic are negotiating a voluntary framework for releasing frontier models to the U.S. government with early security testing.

对工程师的意义 / Engineering Takeaway:

"宁可延期，不发次品"——在 code-gen 这类高可验证任务上，回归（regression）藏不住。这也是为什么评测门禁（eval gates） 现在是模型发布流水线的一等公民，跟我们给 byte-by-byte 加的 QA gate 是同一个道理。

"Delay over ship-broken" — regressions in verifiable tasks like code-gen can't hide. Eval gates are now first-class in release pipelines, same principle as our content QA gate.

📌 本周主线 / This Week's Throughline

三家巨头，三种打法：

• OpenAI 冲能力上限 + agent 化（Sol ultra mode, ChatGPT Work）
• Anthropic 闷声赚企业钱（$30B 营收，云市场分发）
• Google 稳字当头（宁延期不发次品）

对求职者：面试里聊 AI 趋势时，别只背模型名字——讲架构模式（scatter-gather 子代理）、商业逻辑（部署摩擦 vs 模型质量）、工程纪律（eval gates）。这才是 senior/staff 的视角。

Three giants, three strategies: OpenAI pushes capability + agents, Anthropic quietly wins enterprise, Google plays it safe. For interviews: don't recite model names — discuss architecture patterns, business logic, and engineering discipline. That's the senior/staff lens.