美国 SDE New Grad 面试：系统设计 System Design 到底在考什么？

US SDE New Grad Interview: Decoding System Design (System Design Primer)

[!NOTE] 很多 New Grad (NG) 害怕 System Design，觉得这是 Senior 才考的东西。但在 2026 年，System Design 已经成为大厂 (Uber, DoorDash, ByteDance) 筛选优秀 NG 的必考题。

面试官不是指望你能设计出一个完整的 Google Search，而是看你有没有 "Engineering Intuition"。

误区：Don't Over-engineer

• Mistake: 一上来就画 Microservices, Kubernetes, Kafka。
• Correction: 先从 Monolith 开始，随着 Scale 的增加再拆分。展示你的思维演进过程 (Evolution > Final Solution)。

核心考察点 (The "3C" Framework)

1. Clarification (需求澄清)

   • Don't assume anything.
   • Ask: "What is the DAU (Daily Active Users)?" "What is the QPS (Queries Per Second)?" "Is the system read-heavy or write-heavy?"
   • Example: Uber Eats 需要实时性，而 Instagram Feed 允许 Eventual Consistency。

2. Components (组件选择)

   • Database: SQL (MySQL/PostgreSQL) vs. NoSQL (DynamoDB/Cassandra/MongoDB)。
     • Choose SQL for structured data & transactions (Orders, Payments).
     • Choose NoSQL for massive scale & flexible schema (User Logs, Feed).
   • Cache: Redis/Memcached. 放在 DB 前面挡读请求。
   • Load Balancer: Nginx/AWS ELB. 防止单点故障。

3. Constraints (权衡取舍)

   • CAP Theorem: Consistency (一致性) vs. Availability (可用性)。你不可能三角兼得。
   • Trade-off: 为了 High Availability，我们可能牺牲一点 Consistency (比如看到的点赞数有延迟)。

Deep Dive Example: Design a URL Shortener (TinyURL)

这是最经典的 NG System Design 面试题。不要因为它简单就轻视它，面试官能从这个简单的题里挖出无数细节。

1. Requirements (你要设计什么?)

• Functional:
  • 用户输入长链接 (Long URL)，返回短链接 (Short URL)。
  • 用户访问短链接，重定向 (Redirect) 到长链接。
• Non-Functional:
  • High Availability: 服务必须极其稳定，不能挂。
  • Low Latency: 重定向必须极快 (ms级别)。
  • Read-Heavy: 读写比可能是 100:1 (很多人点链接，不仅仅是生成链接)。

2. API Design (怎么调用?)

我们需要两个简单的 REST API：

• POST /api/v1/data/shorten
  • Request: { "longUrl": "https://www.google.com/..." }
  • Response: { "shortUrl": "https://tiny.url/AbCd12" }
• GET /{shortUrl}
  • Response: Status 301 (Permanent Redirect) or 302 (Temporary Redirect) to Long URL.
  • Interview Tip: 问面试官用 301 还是 302？(301 浏览器会缓存，减轻 Server 压力，但没法统计点击量；302 每次都打 Server，适合做 Analytics)。

3. Database Schema (怎么存?)

这个系统数据结构很简单，SQL 或 NoSQL 都可以。但考虑到主要是 KV (Key-Value) 查询，且读极多，我们可以用 NoSQL (如 DynamoDB) 或者带 Cache 的 SQL。

Table: ShortLinks | Column | Type | Description | | :--- | :--- | :--- | | id | BIGINT | Auto-increment Primary Key | | short_code | VARCHAR(7) | The generated code (e.g. "AbCd12") | | long_url | VARCHAR(2048)| Original URL | | created_at | DATETIME | Timestamp |

4. Core Algorithm: Base62 Encoding (这才是考点!)

怎么生成那个 7 位的 short_code？

• 方案 A: Hash (MD5/SHA256)
  • MD5("google.com") -> 长字符串。截取前 7 位？可能会冲突 (Collision)。
• 方案 B: Base62 Conversion (推荐)
  • 使用 [a-z, A-Z, 0-9] 共 62 个字符。
  • 利用 Database 的 Auto-increment ID。
  • 比如 ID = 10000000.
  • 将 10000000 转为 62 进制 -> AbCd12。
  • 因为 ID 是唯一的，所以生成的 Code 也是唯一的！No Collision!

5. Data Flow (把它们串起来)

1. Write Path: User 发送 Long URL -> Server 生成 Global Unique ID (用 Snowflake 算法或 DB Auto-inc) -> 转 Base62 -> 存入 DB (Keys: ID, Code, LongURL) -> 返回 Short URL。
2. Read Path: User 点击 Short URL -> Server 拿到 short_code -> 查 Cache (Redis) -> 如果 Miss，查 DB -> 返回 301/302 Redirect。

常见面试题 (The "Big 4")

1. Design a URL Shortener (TinyURL): (See above) 重点在 Hash vs Base62。
2. Design a Social Feed (Instagram/Twitter): 重点在 "Push vs Pull" models (Fan-out on write vs Fan-out on read)。
3. Design a Chat System (WhatsApp): 重点在 WebSocket 全双工通信, 离线消息处理。
4. Design a Typeahead (Search Autocomplete): 重点在 Trie (Prefix Tree) 数据结构和 Top-k 推荐。

[!TIP] Expert Insight: 面试中如果卡住了，不要慌。回到 "Data Flow" —— 数据从 User 点击开始，经过 LB，到 App Server，查 Cache，查 DB，怎么回来？把这个流程捋顺了，设计就出来了。