Real-World Case Studies

What You Should Understand

• 能用 4-step framework（requirements → high-level design → deep dive → wrap-up）結構化地回答任何 design 題
• 能做 back-of-envelope estimation：從 DAU 推出 QPS 和 storage，並用數字證明 design 決策
• 理解 news feed 的 fanout-on-write vs fanout-on-read tradeoff，以及 celebrity problem 的 hybrid 解法
• 能講出 Netflix 和 Airbnb 從 monolith 到 microservices 的演化故事，以及「何時該拆」的判斷準則
• 理解 object storage（S3）和 file system 的差異，以及為什麼 data lake 建在 object storage 上
• 掌握網站效能的 checklist：CDN、compression、caching、lazy loading、connection reuse、query optimization

A Framework for Design Interviews

System design 面試沒有標準答案，但有標準流程。面試官評的不是你背了多少架構圖，而是你能不能像資深工程師一樣：先問清楚需求、用數字支撐決策、主動講 tradeoff。

The 4-Step Method

以 45 分鐘的面試為例：

Step 1: Requirements Come in Two Kinds

直覺：functional requirements 決定你要畫哪些盒子，non-functional requirements 決定盒子怎麼接、要幾個。同樣是 news feed，10K users 和 500M users 是完全不同的系統。

Back-of-Envelope Estimation

估算不用精確 — 面試官要看的是你的推理鏈和數量級是否合理。常用的錨點數字：

What Interviewers Actually Score

Design Instagram / News Feed

場景：設計一個照片分享 app — 使用者上傳照片、追蹤別人、滑動 feed 看被追蹤者的最新貼文。這是最經典的 design 題，因為它同時考 storage、read-heavy scaling、和 fanout 這個核心 tradeoff。

Step 1: Requirements and Estimation

假設：500M DAU，每人每天上傳 0.2 張照片、刷 10 次 feed，照片平均 2MB。

兩個數字直接決定了架構：（1）73PB/year → 照片必須放 object storage，不是 database；（2）50:1 read ratio → feed 必須靠 cache 而不是每次都查 DB。

The Photo Upload Path

Client → API Gateway → Upload Service → Object Storage (S3)
                            │
                            └→ Metadata DB (photo_id, user_id, caption, s3_key)
                            └→ Queue → Async workers (thumbnails, ML tagging, fanout)

直覺：database 存指標（pointer），object storage 存 bytes。DB row 裡放的是 s3_key，不是 2MB 的照片。這個 pattern 在 ML 系統中完全一樣 — feature store 存 metadata，training data 和 model artifacts 放 object storage。

Feed Generation: Push vs Pull

這是這題的核心 deep dive。瓶頸：user 打開 app 時，系統要從他追蹤的 500 個帳號中撈出最新貼文、排序、回傳 — 在 200ms 內完成，每秒 58,000 次。

Celebrity problem（名人問題）：一個有 100M followers 的帳號發文，純 push 模式要做 100M 次 cache 寫入 — 這會壓垮 fanout pipeline，其他人的貼文也跟著延遲。解法：帳號超過某個 follower 門檻（例如 10K）就標記為 celebrity，發文不 fanout；讀 feed 時把「預先 push 好的 timeline」和「celebrity 的最新貼文」merge 起來。

Timeline Cache

Netflix's Scaling Evolution

場景：Netflix 從 DVD 租借轉型成串流服務，用戶從百萬級長到兩億級。它的架構演化是面試中「monolith vs microservices」的最佳素材 — 因為它示範了何時該拆，而不是「一開始就拆」。

The Evolution Stages

教訓：每一步演化都是被具體的痛逼出來的，不是為了追技術潮流。面試中講「scale when you must, not when you can」會比背 microservices 的好處更加分。

Open Connect: Build Your Own CDN

瓶頸：影片串流佔了 Netflix 流量的 95% 以上。用第三方 CDN 成本極高，而且尖峰時段（晚上八點）品質不穩。

解法：Netflix 打造自己的 CDN — Open Connect。核心想法：

直覺：這是 cache 的極致版本 — 把資料搬到離 user 最近的地方。DS 的類比：與其每次即時算推薦，不如離峰時段 batch 預計算好放進 cache。

Stateless Services and Regional Failover

Netflix Distributed Counter

場景：Netflix 要計數海量事件 — 某影片的觀看次數、某功能的互動數 — 每秒幾萬次遞增，還要能低延遲讀回。「counter」聽起來簡單，卻是分散式系統的經典難題。

Why Counting at Scale Is Hard

直覺：問題的本質是把所有壓力集中在一個點。解法方向必然是：把寫入攤開（partition）、把計算延後（aggregate lazily）、把讀取預先算好（cache）。

The Buffering / Aggregation Approach

Netflix 的 Distributed Counter Abstraction 分成四層：

核心 pattern：把「更新 counter」變成「append event + 稍後聚合」。append 天然可以 partition、可以平行，contention 消失了。這和 data engineering 的 event sourcing、以及 streaming aggregation（Kafka → windowed aggregation → serving store）是同一個思想。

Accuracy vs Latency Tradeoff

如果面試被問到：（1）「怎麼保證不重複計數？」→ 每個 event 帶 unique ID，聚合時 dedupe — 這就是 idempotency。（2）「user 看到的數字會延遲多久？」→ 秒級，取決於 rollup 頻率；讀 cache 保證快但可能 stale。（3）「這跟 A/B test 的 metrics pipeline 有什麼關係？」→ 一模一樣：event log（曝光/點擊）→ batch aggregation → metrics store，實驗平台就是一個大型 distributed counter。

Airbnb's Architectural Evolution

場景：Airbnb 用一個 Ruby on Rails monolith（內部叫 Monorail）從 0 做到全球規模。隨著工程師從十位數長到千位數，Monorail 從加速器變成瓶頸 — 這個 migration 故事是「怎麼拆 monolith」的教科書案例。

Why the Monolith Stopped Working

注意：這些全是組織規模造成的問題，不是技術本身。小團隊的 monolith 沒有這些病 — 這是回答「要不要拆」時最關鍵的判斷。

The SOA Migration

Airbnb 把系統拆成 service-oriented architecture（SOA），並且給 service 分了明確的類型：

Service boundaries around business domains：service 的邊界照著業務領域切（listings、bookings、payments、reviews），不是照技術層切（不要搞出一個「database service」和一個「logic service」）。這樣每個 service 有清楚的 owner 團隊、清楚的職責，才能獨立開發部署。

Migration Lessons

How Amazon S3 Works (Conceptually)

場景：S3 是幾乎所有 data stack 的地基 — training data、feature snapshots、model artifacts、data lake 全放在上面。理解它的設計，你才能回答「為什麼 data lake 建在 S3 而不是資料庫」。

Object Storage vs File System

Key 看起來像路徑（datasets/2026/07/part-001.parquet），但那只是命名慣例 — S3 沒有真正的資料夾，ListObjects 用 prefix 過濾而已。

Durability: Replication and Erasure Coding

S3 宣稱 11 個 9 的 durability（99.999999999%）。做法的核心概念：

直覺：erasure coding 就像 RAID 的一般化 — 用 parity 資訊換取「壞幾顆碟也不掉資料」，而成本遠低於整份複製。

Consistency Model

早期 S3 是 eventual consistency（剛寫入的 object 可能讀不到），這曾是 data pipeline 的地雷 — job A 寫完，job B 立刻 list 卻看不到新檔案。現在 S3 提供 strong read-after-write consistency：PUT 成功後，任何 GET/LIST 都保證看到最新版本。但跨 object 的操作仍然沒有 transaction — 這正是 Delta Lake / Iceberg 這類 table format 存在的理由（在 object storage 上補上 ACID 和 schema）。

Why Data Teams Build Lakes on S3

如果面試被問到：（1）「為什麼 training data 放 S3 不放 PostgreSQL？」→ 容量成本、throughput scan 效能、storage/compute 分離。（2）「S3 上怎麼做到『更新一筆資料』？」→ object immutable，所以靠 table format（Delta/Iceberg）用新檔案 + metadata 版本來模擬 update。（3）「11 個 9 的 durability 等於不會丟資料？」→ durability 不等於 availability，也擋不住你自己誤刪 — 所以還需要 versioning 和 lifecycle policy。

Making Websites Fast

場景：這一節是前面所有章節的收斂 — 一個「網站太慢」的問題，解法散落在 CDN、cache、database、network 各章。面試中被問「怎麼讓系統變快」時，你需要一張有層次的 checklist，而不是隨機丟名詞。

The Performance Checklist

依照 request 的旅程排序 — 由外而內：

Diagnosing Before Optimizing

如果面試被問到：（1）「加了 cache 之後要注意什麼？」→ invalidation 策略、cache stampede（大量 miss 同時打 DB）、資料 staleness 是否可接受。（2）「為什麼 p99 比 median 重要？」→ 高流量下，1% 的慢請求每天影響幾十萬人次，而且慢請求常集中在重度使用者身上。（3）「dashboard 查詢很慢怎麼辦？」→ 同一張 checklist：pre-aggregate（batch 預計算）、加 index、cache 查詢結果、限制掃描範圍（partition pruning）。

Real-World Use Cases

把 4-step framework 用在三個 DS 味的 design 題上 — 這些是 DS/MLE 面試中最可能真正遇到的題型。

Case 1: 設計一個推薦系統的 Serving 架構

Step 1 — Requirements：50M DAU 的電商，首頁要顯示個人化推薦。Latency budget 200ms，每秒尖峰 20K requests。推薦「稍微舊一點」可以接受（分鐘級）。

Step 2 — High-level design：經典的兩段式 — candidate generation（從百萬商品撈幾百個）→ ranking（精排到 top 20）。Embeddings 離線 batch 算好放 object storage，載入 ANN index；user features 放 online feature store。

Step 3 — Deep dive（fanout 思維的重演）：

Step 4 — Wrap-up：瓶頸在 feature fetching（回想 ML pipelines 章）；cold start user 走 popularity fallback；用 A/B test 驗證上線效果。

面試 follow-up：「模型更新怎麼不中斷服務？」→ blue-green model deployment + registry rollback。「怎麼處理爆紅商品？」→ 這就是 hot key，cache + 把 popular items 直接放進所有人的 candidates。

Case 2: 設計即時詐欺偵測系統

Step 1 — Requirements：支付平台，每秒 5K 交易，必須在交易完成前判斷 — hard latency budget 100ms 以內。漏掉 fraud 賠錢，誤殺好交易傷害體驗 — 需要可調的 threshold。

Step 2 — High-level design：Payment API → fraud scoring service（synchronous path）；同時交易 events 進 stream（Kafka）→ 更新 near-real-time features（例如「這張卡過去 10 分鐘的交易次數」）。

Step 3 — Deep dive — feature latency 的分層：

Netflix distributed counter 的教訓直接用上：velocity features（次數統計）就是 streaming counters — event log + windowed aggregation，不要同步 read-modify-write。

Step 4 — Wrap-up：labels 延遲 30-90 天（chargeback）→ 監控用 proxy metrics；模型每天 retrain；決策要留 audit log。

面試 follow-up：「scoring service 掛了怎麼辦？」→ fail-open（放行 + 事後審查）或 fail-closed（拒絕）— 這是 business 決策，要主動問。「threshold 怎麼定？」→ 用 precision-recall tradeoff 接上 cost matrix（回到 evaluation metrics 章）。

Case 3: 設計 Metrics / 實驗平台（A/B Testing Platform）

Step 1 — Requirements：全公司的 A/B testing 平台 — 分流要一致（同一 user 永遠進同組）、metrics 要準（不能重複計數）、實驗結果 dashboard 可以接受小時級延遲。

Step 2 — High-level design：三個子系統 — （1）assignment service：hash(user_id, experiment_id) 決定分組，deterministic 所以不用存每次結果；（2）event pipeline：曝光和轉換 events 進 stream，落地到 data lake；（3）analysis engine：batch 計算各組 metrics + 統計檢定，結果存 metrics store 供 dashboard 查。

Step 3 — Deep dive — 為什麼 metrics pipeline 就是 distributed counter：

Step 4 — Wrap-up：統計部分接回 A/B testing 章（sample size、sequential testing 的 peeking 問題）；平台要防 sample ratio mismatch（SRM）— assignment 和 logging 的比例對不上就是 pipeline bug。

面試 follow-up：「怎麼確保同一 user 永遠同組？」→ deterministic hashing，不是查表。「實驗互相干擾怎麼辦？」→ layered experiment design（每層獨立 hash）。「metrics 算錯一天怎麼辦？」→ raw events 還在 lake，重跑 backfill 即可 — 這就是保留 raw data 的價值。

Hands-on: Estimation and Fanout in Python

Back-of-Envelope Estimation Helper

# Back-of-envelope estimation: turn assumptions into design decisions
SECONDS_PER_DAY = 86_400

def avg_qps(dau: int, actions_per_user_per_day: float) -> float:
    # average queries per second for one action type
    return dau * actions_per_user_per_day / SECONDS_PER_DAY

def peak_qps(avg: float, peak_factor: float = 3.0) -> float:
    # peak traffic is typically 2-5x the daily average
    return avg * peak_factor

def daily_storage_gb(items_per_day: float, item_size_kb: float) -> float:
    # new storage needed per day, in GB
    return items_per_day * item_size_kb / 1_000_000

# --- Instagram-style numbers ---
DAU = 500_000_000
upload_qps = avg_qps(DAU, 0.2)              # ~1,157 writes/sec
feed_qps = avg_qps(DAU, 10)                 # ~57,870 reads/sec
read_write_ratio = feed_qps / upload_qps    # ~50:1 -> read-heavy -> cache

photos_per_day = DAU * 0.2                  # 100M photos/day
storage_per_day = daily_storage_gb(photos_per_day, 2_000)   # ~200,000 GB = 200 TB
storage_per_year_pb = storage_per_day * 365 / 1_000_000     # ~73 PB -> object storage

# Decision chain (what you say in the interview):
# 57K read QPS  -> timeline cache + read replicas, not direct DB reads
# 73 PB/year    -> photos in object storage + CDN; DB stores only metadata

Fanout-on-Write vs Fanout-on-Read Simulation

from collections import defaultdict
import heapq

# --- Shared state ---
follower_index = defaultdict(set)   # author_id -> set of follower ids
posts_by_author = defaultdict(list) # author_id -> [(timestamp, post_id), ...]
timeline_cache = defaultdict(list)  # user_id -> [(timestamp, post_id), ...] (push model)

CELEBRITY_THRESHOLD = 10_000        # hybrid: skip fanout above this

def publish_push(author_id, post_id, ts):
    # Fanout-on-write: O(followers) work at post time, O(1) reads later
    posts_by_author[author_id].append((ts, post_id))
    if len(follower_index[author_id]) >= CELEBRITY_THRESHOLD:
        return  # celebrity: do NOT fan out (hybrid strategy)
    for follower in follower_index[author_id]:
        timeline_cache[follower].append((ts, post_id))

def read_feed_pull(user_id, followees, k=20):
    # Fanout-on-read: merge latest posts from every followee at read time
    # Expensive: O(followees) lookups per feed load
    merged = heapq.merge(
        *(reversed(posts_by_author[f]) for f in followees),
        key=lambda x: x[0], reverse=True,
    )
    return [post for _, post in zip(range(k), merged)]

def read_feed_hybrid(user_id, followees, k=20):
    # Precomputed timeline for regular authors + on-the-fly merge for celebrities
    celebrity_followees = [
        f for f in followees
        if len(follower_index[f]) >= CELEBRITY_THRESHOLD
    ]
    candidates = list(timeline_cache[user_id])          # cheap: already fanned out
    for celeb in celebrity_followees:                   # expensive part is small
        candidates.extend(posts_by_author[celeb][-k:])
    candidates.sort(key=lambda x: x[0], reverse=True)   # rank by recency
    return [post for _, post in candidates[:k]]

# Cost intuition:
# push  -> write cost = followers count; read cost = 1 cache lookup
# pull  -> write cost = 1 append;        read cost = followees count
# hybrid-> bounded write cost AND bounded read cost

Interview Signals

What interviewers listen for:

• 你拿到題目先問 requirements 和 scale，而不是直接畫架構圖
• 你的每個 design 決策都有數字支撐（QPS、storage、latency budget），估算的推理鏈清楚
• 你主動講 tradeoff：fanout push vs pull、consistency vs availability、precompute vs on-the-fly，並根據場景選邊
• 你能引用真實案例的 pattern（Netflix 的 event log + rollup、Airbnb 的 incremental migration）而不是只講抽象名詞
• 你能把 system design 連回 DS 工作：feature freshness 分層、shadow deployment 驗證、raw events 保留在 lake 供 backfill

Practice

Flashcards

Quiz