🏗️ 系统设计 / System Design — Day 98 (Synthesis)

Expert Phase — Cross-Topic Synthesis

综合对比 / Synthesis: 数据库选型决策框架

When to Choose What — 8 DB Types Compared

你是系统设计面试中的候选人，面试官说："为我们设计一个需要存储用户配置、会话数据、内容推荐、时间序列指标、全文搜索和地理位置查询的平台。"这道题的核心不是某一个数据库——而是多个数据库协同工作。

决策矩阵 / Decision Matrix

架构图 / Architecture

核心权衡 / Key Tradeoffs

1. 一致性 vs 可用性

• PostgreSQL: Strong consistency (ACID) → 适合金融、订单
• Redis: Eventual consistency (optional) → 适合缓存、会话
• Cassandra: Eventual by default → 适合写密集、全球分布

2. 读 vs 写优化

• Elasticsearch: 写入慢（index建立），读极快
• InfluxDB: 追加写极快，随机写差
• PostgreSQL: 均衡，靠索引调优

3. Schema 灵活性 vs 查询能力

• MongoDB: 无 schema，但 JOIN 痛苦
• PostgreSQL: Rigid schema，强查询
• 组合策略：核心关系 → SQL，扩展属性 → JSON column

面试中常被考的组合 / Classic Interview Combos

面试技巧 / Interview Tip:

当面试官问"你会用什么数据库？"正确答案几乎永远是：

"这取决于读/写比例、数据结构、一致性需求和查询模式。让我分析一下……"

然后用上面的框架逐一分析。

别踩这个坑 / Common Mistakes

• ❌ 默认所有东西用 PostgreSQL（"RDBMS first"思维）
• ❌ 把 Redis 当主数据库（内存有限，非持久化）
• ❌ 忘记考虑 data locality（地理分布 → 多区域复制）
• ✅ 先问清楚 QPS、数据量、一致性要求，再选型

📚 References

• https://www.postgresql.org/docs/current/index.html
• https://redis.io/docs/latest/
• https://www.elastic.co/guide/index.html
• https://docs.influxdata.com/influxdb/v2/

🧒 ELI5

就像家里的收纳：衣服放衣柜（结构化），零食随便堆一个箱子（非结构化），常用钥匙放门口（缓存），账单按日期归档（时间序列）。不同的东西放不同的地方，效率最高。

💻 算法 / Algorithms — Day 98

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

今天是回溯 block 的第 8 题（共 9 题）。模版一样，变化在于：每一步的 choices 不是固定集合，而是由当前输入字符决定。

问题 / Problem

🔗 LeetCode #17 | 📹 NeetCode

给定数字字符串（如 "23"），返回手机九宫格上所有可能的字母组合。

生活类比： 想象老式 T9 手机打字——每按一个数字键，可能对应多个字母。你想列出所有可能的拼写组合。

映射到回溯模版 / Pattern Mapping

# 通用模版
def backtrack(path, choices):
    if IS_COMPLETE(path):      # len(path) == len(digits)
        result.append(path[:])
        return
    for choice in choices:     # phone_map[digits[len(path)]]
        path.append(choice)
        backtrack(path, NEXT_CHOICES)  # 自动由下一个 digit 决定
        path.pop()

与前几题的区别 / What's Different:

Python 解法 / Solution

from typing import List

def letterCombinations(digits: str) -> List[str]:
    if not digits:
        return []
    
    phone_map = {
        "2": "abc", "3": "def", "4": "ghi", "5": "jkl",
        "6": "mno", "7": "pqrs", "8": "tuv", "9": "wxyz"
    }
    
    result = []
    
    def backtrack(index: int, path: list):
        # Base case: path length == digits length
        if index == len(digits):
            result.append("".join(path))
            return
        
        # Choices: letters for current digit
        for letter in phone_map[digits[index]]:
            path.append(letter)
            backtrack(index + 1, path)  # next digit
            path.pop()  # undo
    
    backtrack(0, [])
    return result

# Trace for "23":
# backtrack(0, []) → choices: a,b,c
#   backtrack(1, [a]) → choices: d,e,f
#     backtrack(2, [a,d]) → DONE → "ad"
#     backtrack(2, [a,e]) → DONE → "ae"
#     backtrack(2, [a,f]) → DONE → "af"
#   backtrack(1, [b]) → "bd","be","bf"
#   backtrack(1, [c]) → "cd","ce","cf"

复杂度 / Complexity:

• Time: O(4^n × n) — 最多4个字母/digit，n是长度，×n是join操作
• Space: O(n) — 递归深度

举一反三 / Connect to Pattern Block

Phone #17 的独特点： choices 不是常量，而是 phone_map[digits[index]] — 每层 choices 都不同，但回溯框架完全不变。

📚 References

• https://leetcode.com/problems/letter-combinations-of-a-phone-number/
• https://neetcode.io/roadmap
• https://en.wikipedia.org/wiki/E.161 (Phone keypad layout history)

🧒 ELI5

想象你要猜一个密码，第一位可能是 a、b、c（数字 2），第二位可能是 d、e、f（数字 3）。你就把所有组合都试一遍：ad、ae、af、bd、be、bf……这就是回溯——系统地把所有路径都走一遍。

🗣️ 软技能 / Soft Skills — Day 98 (Synthesis)

Expert Phase — Fresh Senior/Staff Scenario

新情景题 / Fresh Scenario: 技术路线分歧

问题 / Question:

你是 Staff Engineer。产品团队和你的直属团队在下一个大版本的技术路线上产生了严重分歧——产品团队要求用一套更快交付的第三方 SaaS 方案，而你的工程团队认为应该自研以保持长期控制权和成本优化。两边都有充分的理由，而 VP 要求你在下周的全员会上给出推荐方案。你会怎么做？

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

这是 Staff/Principal 级面试的核心题型：跨组织对齐 + 技术决策 + 向上管理。它考察你是否能：

• 在不确定性下做出有依据的推荐
• 建立信任而不是制造胜负
• 以数据和框架代替情绪和直觉

STAR 分解 / STAR Framework

Situation: 两个有合理立场的团队，高压时间线，VP 期待你的推荐

Task: 在一周内给出可辩护的技术路线决策

Action (Staff 级别的打法):

第一步：信息收集（2天）

- 和产品团队：为什么急？SaaS 方案的具体选项是什么？vendor lock-in 风险是否评估过？
- 和工程团队：自研的资源估算是多少？维护成本？谁来 own it？
- 数据：现有系统的 pain points，用户规模，预期增长

第二步：决策框架（不是"谁赢"，是"什么条件下用哪个"）

                  Make (自研)          Buy (SaaS)
--------------+-------------------+------------------
短期交付速度   |      ❌ 慢         |      ✅ 快
长期成本       |      ✅ 可控       |      ❌ 随规模增
定制化能力     |      ✅ 完全控制   |      ❌ 受限
维护负担       |      ❌ 需要团队   |      ✅ vendor 负责
数据主权       |      ✅ 自有       |      ❓ 取决于合同

第三步：给出有条件的推荐（"It depends + here's the framework"）

✅ 好的推荐措辞：

"在当前 18 个月的产品冲刺周期内，我推荐使用 SaaS 方案，但附带三个条件：数据导出 API 必须可用、合同有明确的退出条款、我们在第 12 个月做 build/buy 再评估。如果这三个条件无法满足，风险太高，我们应该在接下来 6 周内启动自研 MVP 验证。"

❌ 不好的回答 vs ✅ 好的回答

❌ Bad:

"我支持工程团队，自研更灵活。"（过于简单，没有数据支撑，显得偏袒）

❌ Also Bad:

"我支持产品团队，我们需要快速交付。"（放弃了技术视角，不像 Staff）

✅ Good:

"这不是二选一，是在特定约束下的优先级选择。我会用 3 天收集数据，建立决策矩阵，并在全员会上呈现：在什么条件下 SaaS 是对的，在什么条件下自研是对的，以及我的推荐和背后的 assumptions。"

Senior/Staff 级加分点 / Senior Signals

• 建立 decision criteria 而不是 opinions — 面试官想看到结构化思维
• 主动对齐利益相关方 — 在会议前而不是在会议上暴露分歧
• 给出可撤销的决定 — "我们先 SaaS，第 12 月评估" 比 "永远 SaaS" 更有弹性
• 量化风险 — "vendor lock-in 可能导致未来 2 年的迁移成本超过自研成本" 比 "vendor lock-in 不好" 有力

Key Takeaways

1. Staff 不 pick sides — Staff builds decision frameworks
2. 用数据+条件推荐，而不是情绪化立场
3. 向上管理：让 VP 看到你的思考过程，而不只是结论
4. 为决定设置"触发器"——什么条件下推翻这个决定

📚 References

• https://staffeng.com/guides/deciding-technical-direction
• https://pragmaticengineer.com/blog/making-technical-decisions
• https://aws.amazon.com/blogs/enterprise-strategy/build-vs-buy-a-few-lessons-learned/

🧒 ELI5

想象你是班级的"调解员"：A 同学说"我们去打球"，B 同学说"我们去图书馆"。最好的做法不是站队，而是问清楚"我们今天的目标是什么？"，然后根据目标推荐最合适的方案。

🤖 AI — Day 98

News Roundup — July 23, 2026

📰 AI 新闻 / AI News

📌 Story 1: AI 公司隐藏巨额债务 / AI Companies Hiding Massive Debt

来源 / Source: Futurism (citing Nikkei Asia investigation)

根据日本经济新闻（Nikkei Asia）的调查，Alphabet、Microsoft、Amazon、Meta、Oracle 五家科技巨头在资产负债表外隐藏了据报道约 1.65 万亿美元的债务——超过了它们在财务报告中正式披露的约 1.35 万亿美元。这些债务主要来自数据中心租约和 GPU 供应合同。Meta 一家的表外债务据报道约为 4200 亿美元，接近其透明债务的三倍。

部分专家将此与 2001 年 Enron 事件相比较——Enron 通过特殊目的载体隐藏债务，最终崩溃。

对工程师的启示 / Engineering Takeaway:

这说明 AI infra 的投资规模远超公众认知。GPU 集群、数据中心的资本支出正在重塑整个行业的财务结构。作为工程师，理解公司的 AI infra 成本结构越来越重要。

📌 Source: https://futurism.com/artificial-intelligence/ai-companies-hide-debt-off-balance-sheet

📌 Original investigation: https://asia.nikkei.com/business/technology/five-us-tech-giants-hidden-debts-soar-to-1.65tn-on-opaque-ai-funding

📌 Story 2: 陶哲轩用 ChatGPT 探索数学猜想 / Terence Tao Uses ChatGPT for Math Conjecture

来源 / Source: Hacker News / ChatGPT shared conversation

顶级数学家陶哲轩（Terence Tao）公开分享了他用 ChatGPT 探索 Jacobian 猜想反例的对话记录，在 Hacker News 引发热议（据报道 1000+ 点赞）。

这次对话展示了一个顶级领域专家如何"驾驭" LLM：短而精准的问题、大量使用专业术语、快速迭代。社区讨论中有人指出：LLM 的价值与用户的领域深度正相关——越懂行的人越能从中获益，因为他们能快速识别错误并精准导向。

关键洞察 / Key Insight:

"AI 工具放大的是专业能力，而不是替代它。" — 社区讨论总结

HN 链接: https://news.ycombinator.com/item?id=49010345

📌 Story 3 (Synthesis): AI Bubble 讨论升温 / AI Bubble Talk Intensifies

结合上述两条新闻，业界对 AI 泡沫的讨论在 2026 年中段明显升温：

• 一方面，LLM 确实在帮助顶级专家做更高效的工作
• 另一方面，支撑这些模型的基础设施成本据报道远超公开披露的数字

工程师的角度 / Engineering Perspective:

无论宏观叙事如何，技术能力本身仍在快速进步。关注点应放在：

1. 如何用好现有工具（如 Tao 展示的那样）
2. 如何设计成本高效的 AI infra（KV cache、quantization、speculative decoding）
3. 如何评估 AI 功能的真实 ROI

💡 本周 AI 趋势总结 / Weekly AI Theme

"AI as Infrastructure" — AI 不再只是产品功能，而是正在成为基础设施投资的一部分，成本结构与云计算早期相似。对工程师来说，这意味着 AI cost optimization（量化、缓存、批处理）将越来越成为核心技能。

📚 References

• https://futurism.com/artificial-intelligence/ai-companies-hide-debt-off-balance-sheet
• https://asia.nikkei.com/business/technology/five-us-tech-giants-hidden-debts-soar-to-1.65tn-on-opaque-ai-funding
• https://news.ycombinator.com/item?id=49010345

🧒 ELI5

科技公司在说"我们花了 X 买 AI 设备"，但其实悄悄签了很多借钱的合同，真正的花费据报道比公开数字多很多。就像你说"我今天花了 100 块"，但没告诉爸妈你还刷了信用卡。