系統設計方法與 Appier 情境題

系統設計面試框架與時間分配 高頻

系統設計面試沒有標準答案，面試官評估的是思考過程：你能不能把模糊的需求變成清楚的問題、能不能用數字驅動設計決策、能不能看出瓶頸、能不能說清楚取捨。最常見的失敗模式不是「不會」，而是「沒有結構」：一開口就畫 Kafka + Redis + K8s，結果 40 分鐘後還沒講到核心問題。

建議把整場面試當成一個有固定節奏的流程，並且主動宣告你的流程：「我先花幾分鐘釐清需求和規模，接著估算、定 API 和資料模型，畫出高層架構，然後挑兩三個最關鍵的瓶頸深入，最後談取捨與擴展。」這句話本身就是加分，因為它讓面試官知道你有方法，也方便他在中途把你拉到他想考的點。

八步驟框架

1. 釐清需求（Requirements）：功能需求（functional：系統要做什麼）與非功能需求（non-functional：QPS、延遲、可用性、一致性、資料保留期、成本、安全/隱私）。明確寫下「在範圍內 / 不在範圍內」。
2. 估算（Back-of-the-envelope）：QPS（平均與峰值）、讀寫比、儲存量（每日、保留期總量）、頻寬、記憶體（cache 熱資料大小）。目的不是算得精準，而是決定「單機能不能撐」「要不要 sharding」「要不要 cache」。
3. API 設計：列出 3–5 個核心 endpoint（REST 或 gRPC），含參數、回應、冪等性（idempotency key）、分頁、認證。API 讓需求變得具體。
4. 資料模型：核心實體、主鍵、存取模式（access pattern）、索引、分片鍵（shard key）。先講 access pattern 再選 DB，而不是反過來。
5. 高層架構（High-level design）：畫出 client → LB → 服務 → 儲存 / 佇列 / cache 的資料流，並沿著一個請求「走一遍」（read path 與 write path 各一次）。
6. 深入瓶頸（Deep dive）：挑 2–3 個最難的點深入（熱點、一致性、去重、延遲預算、故障處理）。通常面試官會在這裡引導，順著他走。
7. 取捨與擴展（Trade-offs & scaling）：講出你放棄了什麼、為什麼；10 倍流量時哪裡先壞；單點故障在哪；如何監控。
8. 總結（Wrap-up）：用 30 秒複述設計、已知限制與下一步可改進之處。

時間分配建議

釐清需求：該問的問題清單 高頻

Appier 的題目通常只有一句話（「設計一個廣告投放系統」「SDK 會回報大量 JSON，設計統計報表系統」），刻意保留模糊空間。問對問題可以把題目縮到 45 分鐘講得完的範圍，也展現你理解業務。

功能需求（Functional）

• 誰是使用者？終端消費者、廣告主、內部營運、其他服務？不同使用者的 SLA 完全不同。
• 核心使用情境是哪 2–3 個？例如報表系統：是「看即時儀表板」還是「每天下載 CSV」？
• 輸入/輸出長什麼樣？事件格式、欄位數、是否有 schema、大小。
• 需要哪些維度與指標？（報表題）可以任意 group by 嗎？還是固定幾種報表？
• 有沒有多租戶（multi-tenant）？Appier 的產品都是 B2B SaaS，幾乎都有。
• 哪些功能明確不做？例如「計費和反作弊先不談」。

非功能需求（Non-functional）

估算技巧與常用數字 高頻 基礎

估算的目的只有一個：讓數字幫你做設計決策。所以要算的是「會改變架構的數字」：峰值 QPS（決定機器數與是否需要佇列緩衝）、總儲存量（決定 DB 選型與分片）、熱資料大小（決定 cache 能否放進記憶體）、頻寬（決定是否要壓縮、批次）。

QPS 換算

一天 86,400 秒，估算時可以近似成 10⁵ 秒（誤差約 16%，面試可接受；需要時再修正）。

峰值倍數：一般網路服務峰值約平均的 2–3 倍；有明顯晚間高峰或促銷活動（雙 11、推播發送瞬間）的系統，用 5–10 倍估比較安全。推播類系統更特殊：一次發送 100 萬則訊息，接著幾分鐘內的點擊/開啟回流會形成尖峰，要特別說明。

儲存量與頻寬

• 儲存 = 每日筆數 × 每筆大小 × 保留天數 × 副本數（replication factor，常見 3）÷ 壓縮比。
• 頻寬 = QPS × 每筆大小。注意要換成 bit：1 MB/s = 8 Mbps。
• 記憶體 / cache：常用 80/20 法則，熱資料約 20%；或用「最近 N 小時的 key 數 × 每個 key 大小」。
• 機器數 = 峰值 QPS ÷ 單機可承受 QPS（保留 30–50% 餘裕）。

# 面試時可以口算，這段只是把思路寫清楚
DAY = 86_400

def estimate(events_per_day: float, bytes_per_event: int, peak_factor: float = 4,
             retention_days: int = 90, replicas: int = 3, compression: float = 5):
    avg_qps = events_per_day / DAY
    peak_qps = avg_qps * peak_factor
    daily_raw_gb = events_per_day * bytes_per_event / 1e9
    stored_tb = daily_raw_gb * retention_days * replicas / compression / 1e3
    peak_mbps = peak_qps * bytes_per_event * 8 / 1e6
    return dict(avg_qps=round(avg_qps), peak_qps=round(peak_qps),
                daily_raw_gb=round(daily_raw_gb), stored_tb=round(stored_tb, 1),
                peak_ingress_mbps=round(peak_mbps))

print(estimate(1e9, 1_000))
# {'avg_qps': 11574, 'peak_qps': 46296, 'daily_raw_gb': 1000,
#  'stored_tb': 54.0, 'peak_ingress_mbps': 370}

2 的冪次與數量級

延遲數量級（每個工程師都該記得的數字）

下列為經典「Latency Numbers Every Programmer Should Know」的數量級，實際值依硬體而異，面試時記得「差幾個數量級」比記精確值重要。

單機容量的粗略參考

以下是常被引用的「數量級」，用來判斷要不要水平擴展，實際仍需壓測（benchmark）：

• 一般無狀態 API 服務：單機每秒數千到上萬個簡單請求（取決於語言、邏輯與 IO）。
• Redis 單一實例：簡單指令每秒約十萬級 ops；使用 pipeline 可更高；大 key、Lua 長腳本會拖慢（單執行緒執行命令）。
• MySQL 單一 primary：簡單主鍵寫入每秒數千級，視硬體、索引與交易大小而定；讀可以靠 replica 擴展。
• Kafka：單一 broker 可處理每秒數十 MB 到數百 MB 的吞吐，水平擴展靠 partition。

構建積木（Building Blocks）速查 高頻

系統設計就像用樂高組裝：大部分題目都是十幾個標準元件的組合。關鍵是知道每個元件解決什麼問題、代價是什麼、何時不該用。

上圖是一個「萬用骨架」：同步的 request path 盡量短（LB → API → cache/DB），把能延後的工作丟進 MQ，由下游非同步處理。大部分 AdTech 系統都可以從這個骨架變形出來。

可擴展性模式 進階

當估算顯示單機撐不住時，要知道有哪些「標準招式」可用，以及各自的副作用。

無狀態服務 + 水平擴展

把 session、狀態移到外部（Redis、DB、JWT），服務本身無狀態，就能在 LB 後面任意加機器、自動擴縮（K8s HPA）。這是第一個也最便宜的擴展手段。注意 in-process cache 會讓各實例資料不一致。

讀寫分離（Read replica）

寫入 primary、讀取 replica。適合讀多寫少。代價是複寫延遲（replication lag）：剛寫入的資料在 replica 讀不到，需要 read-your-writes 策略（寫後短時間讀 primary、或依版本號判斷）。

分片（Sharding / Partitioning）

依 shard key 把資料拆到多個節點。方法：range（利於範圍查詢但易熱點）、hash（分布平均但範圍查詢困難）、一致性雜湊（節點增減只搬移部分資料）、目錄式（lookup table，最彈性）。難點：跨分片查詢/交易、熱點 key、重新分片（resharding）。

非同步化（Async）

同步路徑只做「必須立刻完成」的事（驗證、寫入佇列、回 202），其餘交給 worker。降低延遲、吸收尖峰，代價是最終一致與錯誤處理變複雜（重試、DLQ、狀態查詢 API）。

批次化（Batching）

把多筆小請求合併：SDK 批次上傳、DB bulk insert、Kafka producer 的 linger.ms/batch.size、Redis pipeline。用少量延遲換大幅吞吐提升，並減少每筆的 overhead（TCP、header、fsync）。

預計算（Precomputation）

把昂貴的計算移到寫入時或離線完成：報表 rollup、推薦結果預先算好放 KV、news feed fan-out on write。讀取變成 O(1) 查表，代價是儲存與「新鮮度」。

CQRS（Command Query Responsibility Segregation）

寫入模型與讀取模型分開。例如寫入 OLTP DB 或事件流，再透過 CDC/串流建出專門給查詢用的 read model（ES、OLAP、KV）。適合讀寫模式差異大的系統（例如 campaign 設定寫入 MySQL，投放服務讀取記憶體索引）。代價是讀模型落後寫模型。

Cache 分層

本地 cache（ns–µs）→ 分散式 cache（約 1ms）→ DB。熱點 key 用本地 cache 擋掉，搭配短 TTL 與主動失效。

背壓（Backpressure）與削峰

下游處理不了時，讓上游放慢（佇列長度上限、429、token bucket），而不是讓整個系統雪崩。

上圖是 CQRS 在廣告系統的典型應用：營運人員對 campaign 的修改寫入 MySQL（需要交易與約束），而每秒數十萬次的投放查詢讀的是記憶體中的倒排索引，兩者透過 CDC 事件同步，可接受數秒延遲。

可用性與一致性取捨 進階

可用性數字與停機時間

串聯降低可用性：一個請求依序依賴 3 個各 99.9% 的服務，整體約 99.9%³ ≈ 99.7%。並聯（冗餘）提升可用性：兩個獨立 99% 的副本，同時掛掉機率 1%×1% = 0.01%，整體約 99.99%（前提是故障彼此獨立，同一 AZ 停電就不獨立）。

提升可用性的手段

• 冗餘（Redundancy）：每層至少 N+1，消除單點故障（SPOF）。包括 LB、服務、DB、佇列、甚至 DNS。
• Failover：主備切換（active-passive）或多活（active-active）。DB failover 要考慮複寫延遲造成的資料遺失（RPO）與切換時間（RTO）。
• Multi-AZ / Multi-region：multi-AZ 處理機房級故障，延遲低（同區域內毫秒級），是預設；multi-region 處理區域級災難，但跨區延遲高、資料一致性難，通常只對關鍵服務做。
• 優雅降級（Graceful degradation）：非核心功能失敗時回預設值。例如 CTR 模型服務超時 → 用 campaign 的歷史平均 CTR；推薦服務掛掉 → 回熱門商品。
• Timeout、重試、熔斷（circuit breaker）、隔艙（bulkhead）：避免故障擴散。重試必須搭配指數退避 + jitter 與冪等性。
• 限流與 load shedding：過載時主動丟棄低優先請求，保住核心功能。

一致性取捨

CAP 定理說明在網路分區（P）發生時，只能在一致性（C）與可用性（A）之間選擇；PACELC 進一步指出「沒有分區時（E），要在延遲（L）與一致性（C）之間取捨」。面試中比較實用的是依資料類型分類：

面試中的扣分行為與加分行為 高頻

情境題 1：SDK 回報大量 JSON 事件的統計報表系統 高頻 深入

題目（Appier 真題）：「客戶的 App / 網站裝了我們的 SDK，SDK 會把使用者行為（開啟、瀏覽、加入購物車、購買、廣告曝光/點擊）以 JSON 回報給後端。請設計一個統計報表系統，讓客戶能查詢各種指標。」這是 AdTech/MarTech 最核心的資料管線，幾乎涵蓋了分散式系統的所有經典問題：高吞吐寫入、重複、遲到、近似計算、多租戶、重算。

需求釐清

估算

• 平均 QPS（事件）：10⁹ ÷ 86,400 ≈ 11,600/s；峰值約 46,000/s。
• SDK 每批平均 20 筆 → HTTP 請求峰值約 2,300/s，幾台到十幾台 collector 即可（保留餘裕與 AZ 冗餘）。
• 每筆 JSON 約 1 KB → 每日 1 TB raw；峰值 ingress 約 46 MB/s（約 370 Mbps）；gzip 後傳輸量可降到數分之一。
• Kafka 保留 3 天、replication factor 3：約 9 TB（壓縮前），壓縮後再小數倍。
• S3 Parquet（列式 + 壓縮常見 5–10 倍）：每日約 100–200 GB，一年約 40–70 TB，S3 成本可接受。
• 聚合表：假設 5,000 個租戶 × 50 種事件 × 24 小時 × 維度組合數百 → 每天數千萬列的小時級聚合，ClickHouse 輕鬆處理。

API 設計

POST /v1/events HTTP/1.1
Host: collect.example.com
X-App-Key: ak_live_xxx
Content-Type: application/json
Content-Encoding: gzip

{
  "sdk_version": "3.2.1",
  "device_id": "d-7f3a...",
  "sent_at": 1762156800.120,
  "events": [
    {"event_id": "2b1e6c0e-...", "name": "add_to_cart", "client_ts": 1762156790.002,
     "user_id": "u-123", "props": {"sku": "A-1", "price": 590, "currency": "TWD"}}
  ]
}

HTTP/1.1 202 Accepted
{"accepted": 1, "rejected": []}
# 413 Payload Too Large / 401 / 429 (帶 Retry-After) / 5xx：SDK 依碼決定是否重試

GET /v1/reports/query?app_id=42&metrics=events,unique_users,revenue
    &dimensions=date,country&filters=event_name:purchase,platform:ios
    &from=2026-10-01&to=2026-11-01&granularity=day&tz=Asia/Taipei
Authorization: Bearer <token>

200 OK
{"rows": [{"date": "2026-10-01", "country": "TW", "events": 18234, "unique_users": 9120, "revenue": 1203400}],
 "meta": {"approximate": ["unique_users"], "data_freshness": "2026-11-03T13:05:00Z"}}

POST /v1/reports/exports   → 202 {"job_id": "exp_91"}   # 大查詢非同步匯出
GET  /v1/reports/exports/exp_91 → {"status": "done", "url": "https://s3-presigned..."}

設計重點：事件 API 支援批次 + gzip；回應 202 Accepted 代表「已持久化到佇列」而非「已處理」；查詢 API 回傳 meta.approximate 告知哪些指標為近似值，以及資料新鮮度，讓前端顯示「資料更新至 13:05」。

資料模型

-- ClickHouse：小時級預聚合表（AggregatingMergeTree 會在背景合併相同 ORDER BY key 的列）
CREATE TABLE events_hourly
(
    app_id      UInt32,
    hour        DateTime,
    event_name  LowCardinality(String),
    country     LowCardinality(String),
    platform    LowCardinality(String),
    cnt         SimpleAggregateFunction(sum, UInt64),
    revenue     SimpleAggregateFunction(sum, Float64),
    users       AggregateFunction(uniq, String)        -- 近似 distinct 的中間狀態，可跨小時合併
)
ENGINE = AggregatingMergeTree
PARTITION BY toYYYYMMDD(hour)
ORDER BY (app_id, hour, event_name, country, platform)
TTL hour + INTERVAL 400 DAY;

-- 由明細表（或 Kafka engine 表）自動寫入聚合表
CREATE MATERIALIZED VIEW mv_events_hourly TO events_hourly AS
SELECT app_id, toStartOfHour(event_time) AS hour, event_name, country, platform,
       count() AS cnt, sum(revenue) AS revenue, uniqState(user_id) AS users
FROM events_detail
GROUP BY app_id, hour, event_name, country, platform;

-- 報表查詢：小時 rollup 到日；uniqMerge 合併 HLL 類狀態
SELECT toDate(hour, 'Asia/Taipei') AS day, country,
       sum(cnt) AS events, uniqMerge(users) AS unique_users, sum(revenue) AS revenue
FROM events_hourly
WHERE app_id = 42 AND event_name = 'purchase'
  AND hour >= '2026-10-01 00:00:00' AND hour < '2026-11-01 00:00:00'
GROUP BY day, country
ORDER BY day, country;

高層架構

Write path 走一遍：SDK 累積事件後 gzip 上傳 → LB → collector 驗證 app key、大小、配額，補上 server 時間，寫入 Kafka events.raw（等 ack 才回 202）→ validator 依租戶的 event schema 驗證、補 geo/IP 資訊，合格進 events.clean、不合格進 DLQ → Flink 依 event_id 去重、依 event time 做 1 分鐘/1 小時視窗聚合寫入 ClickHouse；同時 S3 sink 把明細寫成 Parquet → 每天 Spark 從 S3 重算前一天的精確數字覆蓋 ClickHouse 分區。

Read path：dashboard → Query API 驗證 token 並強制注入 tenant 過濾 → 查 Redis 快取 → miss 則把查詢轉成 ClickHouse SQL（只允許白名單維度與指標）→ 結果快取（TTL 依時間範圍：今天的資料 1 分鐘、歷史資料 1 小時）。

深入 1：SDK 端的 batching、壓縮與重試

SDK 是整條管線最不可控的一端（使用者網路差、App 被殺、時鐘不準），設計原則是「至少一次送達（at-least-once）+ 伺服器端去重」：

• Batching：達到 N 筆、或經過 T 秒、或 App 進入背景時 flush。減少請求數與電量消耗。
• 持久化佇列：事件先寫入本地 SQLite/檔案，送成功才刪除；App 被殺也不遺失。佇列有上限，滿了丟最舊或低優先事件。
• 壓縮：JSON 重複欄位多，gzip 常能壓到原本的數分之一，對行動網路很重要。
• 重試：只對網路錯誤、408、429、5xx 重試；指數退避 + full jitter；尊重 Retry-After；4xx（如 400 格式錯誤）不重試，避免毒藥訊息卡住佇列。
• event_id：在 client 端產生 UUID，重送時不變，讓伺服器端能去重。
• 時鐘偏移：同時送 client_ts（事件發生時間）與 sent_at（送出時間），伺服器以 server_received - sent_at 估算偏移量校正 event time。
• 遠端設定：取樣率、flush 間隔可由伺服器下發，緊急時可降低流量（kill switch）。

import gzip, json, random, time, uuid
import requests

RETRYABLE = {408, 429, 500, 502, 503, 504}

class EventUploader:
    """簡化版 SDK 上傳器：真實 SDK 會在背景執行緒執行，並把 queue 存在磁碟。"""

    def __init__(self, endpoint, app_key, max_batch=50, max_wait=10.0, max_queue=5_000):
        self.endpoint, self.app_key = endpoint, app_key
        self.max_batch, self.max_wait, self.max_queue = max_batch, max_wait, max_queue
        self.queue = []
        self.last_flush = time.time()

    def track(self, name, user_id=None, **props):
        if len(self.queue) >= self.max_queue:
            self.queue.pop(0)                        # 背壓：丟最舊，避免無限成長
        self.queue.append({"event_id": str(uuid.uuid4()), "name": name,
                           "client_ts": time.time(), "user_id": user_id, "props": props})
        if len(self.queue) >= self.max_batch or time.time() - self.last_flush >= self.max_wait:
            self.flush()

    def flush(self):
        batch = self.queue[: self.max_batch]
        if not batch:
            return
        body = gzip.compress(json.dumps({"sent_at": time.time(), "events": batch}).encode())
        headers = {"X-App-Key": self.app_key, "Content-Type": "application/json",
                   "Content-Encoding": "gzip"}
        for attempt in range(6):
            try:
                resp = requests.post(self.endpoint, data=body, headers=headers, timeout=5)
                status = resp.status_code
            except requests.RequestException:
                resp, status = None, None            # 網路錯誤：可重試
            if status in (200, 202):
                break
            if status is not None and status not in RETRYABLE:
                break                                # 4xx：重試也不會成功，丟棄這批（並記錄）
            retry_after = float(resp.headers.get("Retry-After", 0)) if status == 429 else 0
            time.sleep(max(retry_after, random.uniform(0, min(60, 2 ** attempt))))  # full jitter
        else:
            return                                   # 重試用盡：保留在 queue，下次再送
        del self.queue[: len(batch)]
        self.last_flush = time.time()

深入 2：無狀態 collector 與「何時回 202」

Collector 只做最輕量的事：認證（app key 查本地 cache）、大小與配額檢查、解壓、補 server 欄位、寫 Kafka。重要決策是等 Kafka ack 再回 202（acks=all + idempotent producer），這樣回 202 就代表資料已持久化在多個 broker；代價是延遲多幾毫秒。若 Kafka 短暫不可用，可以寫入本地磁碟 spool 檔、稍後補送，或直接回 503 讓 SDK 重試（SDK 本身有持久化佇列，所以回 503 是安全的）。

import gzip, json, time
from fastapi import FastAPI, Header, HTTPException, Request
from aiokafka import AIOKafkaProducer

app = FastAPI()
producer = None
MAX_BODY = 1_000_000          # 壓縮後上限
MAX_INFLATED = 10_000_000     # 解壓後上限，防 gzip bomb
MAX_EVENTS = 500

@app.on_event("startup")
async def startup():
    global producer
    producer = AIOKafkaProducer(bootstrap_servers="kafka:9092", acks="all",
                                enable_idempotence=True, linger_ms=5,
                                compression_type="lz4")
    await producer.start()

@app.post("/v1/events", status_code=202)
async def ingest(request: Request, x_app_key: str = Header(...)):
    app_id = await auth_cache.get_app_id(x_app_key)          # 本地 LRU + Redis，避免每次打 DB
    if app_id is None:
        raise HTTPException(401)
    if not await tenant_quota.allow(app_id):                 # 每租戶 token bucket
        raise HTTPException(429, headers={"Retry-After": "30"})
    raw = await request.body()
    if len(raw) > MAX_BODY:
        raise HTTPException(413)
    if request.headers.get("content-encoding") == "gzip":
        raw = safe_gunzip(raw, limit=MAX_INFLATED)           # 超過上限就丟例外 → 413
    payload = json.loads(raw)
    received = time.time()
    skew = received - float(payload.get("sent_at", received))
    key = f"{app_id}:{payload.get('device_id', '')}".encode()
    pending, rejected = [], []
    for i, e in enumerate(payload.get("events", [])[:MAX_EVENTS]):
        if not isinstance(e, dict) or "event_id" not in e or "name" not in e:
            rejected.append(i)                               # 完整 schema 驗證留給下游
            continue
        e.update(app_id=app_id, server_ts=received,
                 event_ts=float(e.get("client_ts", received)) + skew)
        pending.append(await producer.send("events.raw", json.dumps(e).encode(), key=key))
    for fut in pending:
        await fut                                            # 全部 ack 後才回 202
    return {"accepted": len(pending), "rejected": rejected}

深入 3：Schema 驗證與 DLQ

• Schema registry：每個租戶的自訂事件在後台定義（欄位名、型別、必填），存在 MySQL 並快取到 validator。內部 topic 之間建議用 Avro/Protobuf + schema registry，比 JSON 省空間且有相容性檢查（backward/forward compatibility）。
• 驗證失敗不丟棄：送進 events.dlq，附上錯誤原因、原始 payload、schema 版本。提供 DLQ 儀表板讓客戶看到「你的 purchase 事件 price 欄位型別錯誤，佔 3%」。
• 可重播：修正 schema 或程式後，從 DLQ 重新送回 events.clean。因為下游有 event_id 去重，重播是安全的。
• 寬鬆 vs 嚴格：未知欄位保留在 props（JSON 欄位）而不是拒絕，避免 SDK 新版本上線時大量進 DLQ。

深入 4：串流聚合（Flink）vs 批次（Spark）

常見答案是兩者並用（Lambda 架構的變形）：Flink 提供近即時的「暫定數字」，每天 Spark 從 S3 重算前一天並覆蓋 ClickHouse 的日分區，作為最終精確數字（計費依據）。另一派是 Kappa 架構：只有串流，重算時重播事件流；如果 Kafka 有長保留期（或 tiered storage）且 Flink 作業夠穩定，可以省去維護兩套邏輯的成本。面試中說出兩者取捨即可，維護兩套邏輯可能導致數字不一致是 Lambda 的主要缺點，可以用同一套 SQL（Flink SQL / Spark SQL）或共用函式庫緩解。

深入 5：去重、遲到事件與 watermark

重複從哪來：SDK 重送、collector 寫 Kafka 成功但回應前崩潰、consumer 處理後提交 offset 前崩潰（at-least-once）。所以去重必須在下游做，依據是 client 產生的 event_id：

• 串流：Flink 以 event_id 為 key 的 keyed state（RocksDB backend）+ TTL（例如 24 小時），見過就丟。狀態大小 ≈ 每日事件數 × key 大小，10 億 × 約 40 bytes ≈ 數十 GB，分散在各 TaskManager 可行。若想省空間可用 Bloom filter（有少量誤判把新事件當重複）。
• 批次：Spark 對當日分區做 dropDuplicates(["event_id"])，精確。
• 跨很長時間的重複（裝置離線三天後重送）由批次重算處理。

遲到事件：手機離線時事件會晚到數小時甚至數天。報表要以 event time（事件發生時間）而非 processing time 分桶，否則「昨天的購買」會被算到今天。Flink 用 watermark 表示「我認為 event time 早於 W 的事件已經到齊」；視窗在 watermark 越過視窗結束時間時輸出。可設定 allowed lateness 讓稍晚的事件更新已輸出的結果（sink 需支援 upsert），更晚的事件走 side output 寫到 S3，由每日批次校正。

from collections import defaultdict

WINDOW = 60            # 1 分鐘 tumbling window（秒）
MAX_DELAY = 300        # watermark = 目前看過最大 event time - 5 分鐘

class WindowCounter:
    """示意 Flink 的 event-time 視窗 + watermark + 去重（單機版）。"""

    def __init__(self, sink):
        self.counts = defaultdict(int)       # (app_id, event_name, window_start) -> count
        self.seen = {}                       # event_id -> 過期時間；實務用帶 TTL 的 keyed state
        self.max_ts = 0.0
        self.sink = sink

    def on_event(self, e):
        if e["event_id"] in self.seen:
            return                           # 重複事件
        self.seen[e["event_id"]] = e["event_ts"] + 86_400
        self.max_ts = max(self.max_ts, e["event_ts"])
        watermark = self.max_ts - MAX_DELAY
        start = int(e["event_ts"]) // WINDOW * WINDOW
        if start + WINDOW <= watermark:
            self.sink.late(e)                # 視窗已關閉：side output，交給批次校正
            return
        self.counts[(e["app_id"], e["name"], start)] += 1
        self.fire(watermark)

    def fire(self, watermark):
        ready = [k for k in self.counts if k[2] + WINDOW <= watermark]
        for key in ready:
            self.sink.emit(key, self.counts.pop(key))   # sink 以 key upsert，重複輸出也冪等

深入 6：Exactly-once 的實際意義

端到端的 exactly-once 實際上是「at-least-once 傳遞 + 冪等/交易性處理」。Flink 透過 checkpoint 記錄 Kafka offset 與運算狀態，故障時從 checkpoint 恢復並重播；sink 端要嘛支援交易（Kafka transactional producer 的 two-phase commit），要嘛是冪等寫入（以 (app_id, event_name, window_start) 為 key upsert，重寫同樣的值不影響結果）。ClickHouse 這類 OLAP 的 insert 並非傳統交易，常見做法是：串流寫入「可覆蓋」的近即時表，最終數字由批次覆寫分區保證正確。

深入 7：預聚合 cube 與 rollup

若有 d 個維度，所有 group by 組合有 2^d 種（cuboid）。10 個維度就是 1,024 種組合，而且高基數維度（如 user_id、sku）會讓聚合後的列數接近原始資料，失去預聚合的意義。實務策略：

• 只預算常用組合：依 dashboard 實際查詢日誌決定要建哪些 cuboid（例如「日 × 國家 × 平台」「小時 × campaign」）。
• 時間 rollup：分鐘級保留 7 天、小時級保留 90 天、日級保留數年，用 TTL 自動清除；查詢依時間範圍自動選表。
• 高基數維度不進 cube：需要時走明細表（ClickHouse 明細表本身就能在數秒內掃描數十億列）或非同步匯出。
• Druid 的 ingestion-time rollup：在寫入時就依時間粒度與維度合併，大幅降低儲存。代價是失去明細。

深入 8：精確 vs 近似（HyperLogLog）

unique users 是報表最貴的指標：count 可以直接相加，但「10/1 的 UU + 10/2 的 UU ≠ 兩天的 UU」，因為同一人可能兩天都來。精確計算需要保存完整的 user 集合。

import redis
r = redis.Redis()

# 每個 (app, 日期) 一個 HLL；每個 key 最多約 12KB，與 unique 數無關
def record(app_id: int, day: str, user_id: str):
    r.pfadd(f"uu:{app_id}:{day}", user_id)

def unique_users(app_id: int, days: list):
    keys = [f"uu:{app_id}:{d}" for d in days]
    return r.pfcount(*keys)      # 多個 key 時回傳「聯集」的估計值，等同合併後再數

深入 9：多租戶隔離

• 資料隔離：每一層都帶 app_id/tenant_id；查詢 API 由伺服器端從 token 推出 tenant 並強制加入 WHERE 條件，絕不信任 client 傳來的 tenant 參數。ClickHouse 可加 row policy 作為第二道防線。
• Noisy neighbor：每租戶的寫入配額（token bucket）與查詢併發上限；超大客戶可給專屬 Kafka topic/partition 或專屬 ClickHouse 叢集；查詢設 max_execution_time、max_memory_usage 防止一個大查詢拖垮叢集。
• 熱點：如果 partition key 只用 app_id，大客戶會讓單一 partition 過熱，所以用 hash(app_id, device_id)。
• 隱私：PII（email、電話）在 collector 或 validator 端雜湊化；支援依 user 刪除（GDPR），S3 上的 Parquet 需定期重寫或以加密金鑰銷毀（crypto-shredding）處理。

深入 10：回補（Backfill）與重算

1. 觸發情境：聚合邏輯有 bug、新增指標要算歷史資料、DLQ 修復後重送、遲到事件校正。
2. Spark 從 S3 讀指定日期分區的 raw Parquet，套用新版邏輯，產出聚合結果到暫存表。
3. 驗證（列數、總和與舊版差異在預期內）後，以分區為單位原子替換（ClickHouse ALTER TABLE ... REPLACE PARTITION），查詢端不會看到半套資料。
4. 工作必須冪等：同一日期重跑多次結果相同；由 Airflow 管理，可平行跑多天但限制併發，避免擠壓線上查詢資源。
5. 清除受影響範圍的查詢快取。

瓶頸與取捨總結

面試官可能的追問

情境題 2：設計廣告投放系統（Ad Serving / RTB Bidder） 高頻 深入

題目（Appier 真題）：「設計一個廣告投放系統。」範圍非常大，第一步一定要縮小：是自家網站/App 的廣告伺服器（ad server），還是在廣告交易平台（ad exchange）上即時競價的 DSP bidder？以程式化廣告平台常見情境，建議主動選擇 DSP 的 RTB bidder + campaign 管理 + 追蹤計費，因為它最能展現低延遲與分散式的設計能力。更多 AdTech 名詞（OpenRTB、first/second price、bid shading）請參考 第 14 章。

需求釐清

估算

• 流量：峰值 50 萬 QPS；假設單台 bidder 可處理約 5,000 QPS（含模型推論），需約 100 台以上，再加 30–50% 餘裕並分散到多個 region/AZ。
• 頻寬：OpenRTB JSON 約 1–2 KB → 峰值約 0.5–1 GB/s 入流量（4–8 Gbps），回應只有出價時才有內容。
• Campaign 數：數萬個 active line items，加上 targeting 規則，記憶體中數百 MB 以內 → 每台 bidder 可以放完整索引。
• 使用者 profile：數億到十億個 user/device ID，每筆數百 bytes 到 1 KB → 數百 GB 到 TB，需要分散式低延遲 KV（Aerospike、Redis Cluster、ScyllaDB 等），單次查詢需在約 1–5ms 內。
• 事件：若勝率約 10%，曝光約 5 萬/s；點擊率以 0.1–1% 計約數十到數百/s。bid log 全量可能每天數十 TB，通常取樣或只保留精簡欄位。

API 設計

# 1) Exchange → Bidder（OpenRTB，簡化）
POST /rtb/v1/bid
{"id": "req-1", "tmax": 100,
 "imp": [{"id": "1", "banner": {"w": 300, "h": 250}, "bidfloor": 0.5}],
 "app": {"bundle": "com.example.news"}, "device": {"ifa": "abcd-...", "geo": {"country": "TWN"}, "os": "iOS"},
 "user": {"id": "exch-user-9"}}

200 OK  → {"id": "req-1", "seatbid": [{"bid": [{"impid": "1", "price": 1.8, "crid": "cr-77",
          "adm": "...", "nurl": "https://win.example.com/w?b=...&p=${AUCTION_PRICE}"}]}]}
204 No Content  → 不出價（必須在 tmax 內回，否則等同不出價且可能被降流量）

# 2) 追蹤
GET /w?b=<signed_bid_token>&p=<encrypted_price>     win notice（exchange 回呼，帶清算價）
GET /i?t=<signed_token>                              impression pixel（回 1x1 或 204）
GET /c?t=<signed_token>                              click → 302 轉址到廣告主落地頁

# 3) Campaign 管理（給廣告主 / 營運）
POST  /v1/campaigns                  建立
PATCH /v1/campaigns/{id}             修改預算、狀態、targeting（需樂觀鎖 version）
GET   /v1/campaigns/{id}/stats?from=&to=

追蹤 URL 中的 token 由 bidder 在出價時簽章（HMAC），內含 bid_id、campaign_id、creative_id、時間戳等，tracker 驗章後即可得知所有資訊，不必查 DB，也防止偽造；token 帶過期時間以防重放。

資料模型

高層架構

深入 1：100ms 延遲預算怎麼分

關鍵原則：(1) 整體有一個 deadline，每個下游呼叫用「剩餘時間」當 timeout，時間快到就直接回 204；(2) 網路呼叫越少越好，能在記憶體做的就不要遠端查；(3) 注意尾延遲：一次請求平行呼叫 5 個服務，任一個慢就整體慢，所以要用 hedged request 或嚴格 timeout；(4) 語言 runtime 的 GC 停頓會吃掉預算，Go/Java 要減少配置、物件池化。

深入 2：Targeting 倒排索引

暴力法是對每個 bid request 掃過所有 campaign 檢查 targeting 條件：數萬個 campaign × 數十萬 QPS 太慢。倒排索引把「屬性值 → 符合的 campaign 集合」預先建好，查詢時只做集合交集：

from collections import defaultdict

DIMENSIONS = ["country", "os", "ad_size"]      # 單值維度：請求只有一個值

class TargetingIndex:
    def __init__(self, campaigns):
        self.by_value = defaultdict(set)        # (dim, value) -> {campaign_id}
        self.unrestricted = defaultdict(set)    # dim -> 該維度沒設限制的 campaign
        self.by_segment = defaultdict(set)      # segment -> {campaign_id}
        self.no_segment = set()
        self.all_ids = set()
        for c in campaigns:
            cid, t = c["id"], c["targeting"]
            self.all_ids.add(cid)
            for dim in DIMENSIONS:
                values = t.get(dim)
                if values:
                    for v in values:
                        self.by_value[(dim, v)].add(cid)
                else:
                    self.unrestricted[dim].add(cid)
            if t.get("segments"):               # 多值維度：命中任一 segment 即可（OR）
                for s in t["segments"]:
                    self.by_segment[s].add(cid)
            else:
                self.no_segment.add(cid)

    def match(self, req, user_segments):
        result = set(self.all_ids)
        for dim in DIMENSIONS:                  # 各維度之間是 AND
            result &= self.by_value.get((dim, req.get(dim)), set()) | self.unrestricted[dim]
            if not result:
                return result                   # 提早結束
        seg_hits = set(self.no_segment)
        for s in user_segments:
            seg_hits |= self.by_segment.get(s, set())
        return result & seg_hits

idx = TargetingIndex([
    {"id": 1, "targeting": {"country": ["TW", "JP"], "os": ["iOS"], "segments": ["sports"]}},
    {"id": 2, "targeting": {"country": ["TW"]}},
])
print(idx.match({"country": "TW", "os": "iOS", "ad_size": "300x250"}, ["sports", "travel"]))  # {1, 2}

• 生產級做法：集合改用 Roaring bitmap（campaign 編成連續整數），交集是位元運算；排除條件（NOT）用差集；複雜布林表達式可參考 Yahoo 的「Indexing Boolean Expressions」論文中的 conjunction index。
• 更新：Index builder 從 MySQL CDC 收到變更，定期產生完整快照（例如每幾分鐘）並推送增量。bidder 用 double buffering：在背景建好新索引，再以原子指標交換（atomic pointer swap），讀取端完全不加鎖。
• 預算與狀態：預算用完、暫停的 campaign 要能「秒級」從候選移除，這部分不走完整重建，而是由 pacing 模組的本地旗標過濾。

深入 3：CTR 預估服務與出價

• 出價公式（以 CPC 計費的 campaign 為例）：eCPM = pCTR × 廣告主願付 CPC × 1000；CPA 目標則是 pCTR × pCVR × target CPA × 1000。最後再依拍賣機制（first price 需 bid shading）調整。
• 特徵：使用者（segments、近期行為）、情境（app、時段、裝置、地區）、廣告（campaign、素材歷史表現）與交叉特徵。線上特徵需要與訓練時一致（training-serving skew 是常見 bug 來源），所以用 feature store 統一定義。
• 部署形式：in-process（最低延遲，但模型更新要重載、語言綁定）vs 獨立模型服務（gRPC，便於 GPU 與獨立擴展，但多一跳網路）。一個 request 有多個候選時，一次批次推論所有候選。
• 降級：模型服務超時 → 使用 campaign 的歷史平均 CTR 或保守出價；新 campaign 冷啟動用同類平均值 + 探索（exploration）流量。
• 上線：shadow mode（只算不用）比對 → 小流量 A/B → 逐步放量；持續監控預估 CTR 與實際 CTR 的校準（calibration）。

深入 4：Budget pacing 與分散式預算扣減

問題：同一個 campaign 同時在上百台 bidder、多個 region 被出價。如果每次出價都去中央 DB 檢查並扣款，中央節點會成為瓶頸且增加延遲；如果完全不協調，預算會嚴重超支。另外「出價」不等於「花費」：要等勝標（win notice）才知道實際花費，中間有時間差。

1. 預算租約（budget lease）：Budget service 把 campaign 剩餘預算切成小額度發給各 bidder（例如每次申請「約 1 分鐘的預估花費」或剩餘預算的一小比例）。bidder 在本地扣減，用完再申請；額度愈接近用完，發得愈小。最大超支 ≈ 所有 bidder 手上未結清額度 + 在途出價。
2. 真實花費：win notice 與曝光事件 → Kafka → Flink 依 campaign 累加 → 寫回 budget service 與 MySQL ledger。這是計費的 source of truth。
3. Pacing：預算不能在早上 9 點就花完（錯過晚間黃金時段）。依流量預測曲線算出「到現在為止應該花多少」，每分鐘比較實際花費，調整出價機率（throttling）或出價倍率。
4. 預算耗盡：budget service 廣播停止訊號（pub/sub），bidder 立刻把 campaign 標記為不可出價；租約到期也會自然停止。

import redis
r = redis.Redis()

# 原子地從剩餘預算中切出一塊額度（單位：micro 元，用整數避免浮點誤差）
LEASE_LUA = r.register_script("""
local remaining = tonumber(redis.call('GET', KEYS[1]) or '0')
if remaining <= 0 then return 0 end
local grant = math.min(remaining, tonumber(ARGV[1]))
redis.call('DECRBY', KEYS[1], grant)
return grant
""")

class LocalBudget:
    """每台 bidder 對每個 campaign 持有的本地額度。"""
    def __init__(self, campaign_id, chunk_micros):
        self.key = f"budget:{{{campaign_id}}}:remaining"   # {} 為 Redis Cluster hash tag
        self.chunk = chunk_micros
        self.balance = 0

    def try_spend(self, bid_micros):
        if self.balance < bid_micros:
            self.balance += LEASE_LUA(keys=[self.key], args=[self.chunk])  # 實務上在背景預先補充
        if self.balance < bid_micros:
            return False                     # 預算不足，不出價
        self.balance -= bid_micros           # 以出價保守預扣；勝標後依清算價結算差額
        return True

class Pacer:
    """依計畫花費曲線調整出價機率（簡化的比例控制）。"""
    def __init__(self, daily_budget, planned_fraction_by_minute, k=0.5):
        self.budget, self.plan, self.k = daily_budget, planned_fraction_by_minute, k
        self.p = 0.5

    def update(self, minute_of_day, spent_so_far):
        planned = self.budget * self.plan[minute_of_day]      # 累積計畫花費
        error = (planned - spent_so_far) / self.budget         # 正：花太慢；負：花太快
        self.p = min(1.0, max(0.01, self.p + self.k * error * 10))
        return self.p                                          # bidder 以機率 p 參與競價

深入 5：Frequency capping（Redis）

「同一使用者每天最多看到這個 campaign 3 次」。做法：每個使用者一個 Redis Hash，field 為 campaign:日期，bid 時一次 HGETALL/HMGET 取回所有計數並過濾候選；曝光時（tracker 收到 impression）才 HINCRBY。

FC_TTL = 7 * 86_400

def frequency_ok(r, user_id, candidates, caps, day):
    fields = [f"{cid}:{day}" for cid in candidates]
    counts = r.hmget(f"fc:{user_id}", fields)            # 一次網路往返
    return [cid for cid, n in zip(candidates, counts)
            if int(n or 0) < caps[cid]]

def on_impression(r, user_id, campaign_id, day):
    pipe = r.pipeline()
    pipe.hincrby(f"fc:{user_id}", f"{campaign_id}:{day}", 1)
    pipe.expire(f"fc:{user_id}", FC_TTL)                 # 不活躍使用者自動清除
    pipe.execute()

• 近似可接受：bid 時讀、曝光時寫，中間有時間差，同一使用者在幾百毫秒內被多個 exchange 請求時可能超過上限 1 次，業界通常接受。
• 省一次呼叫：若 user profile KV 也能存計數，與 profile 一起讀取，減少網路往返。
• Redis 故障：fail-open（當作沒看過，可能過度曝光）或 fail-closed（不出價，損失營收）。通常對有嚴格頻次要求的 campaign fail-closed，其餘 fail-open，並告警。
• 多 region：使用者通常固定在某區域，各 region 獨立計數即可，跨區只做非同步同步。

深入 6：曝光/點擊追蹤與計費

• Tracker：高 QPS、極簡（驗 token → 寫 Kafka → 回 204/302）。點擊轉址的延遲直接影響使用者體驗與廣告主轉換率，必須快。
• 去重：同一 bid_id 的 win notice / impression 可能重複（重試、瀏覽器重整），計費前以 bid_id/impression_id 去重（Flink keyed state 或 DB unique key）。
• 計費 ledger：只增不改（append-only）的帳本記錄每筆花費（campaign、金額、清算價、時間、來源事件 id），金額用整數 micros 或 Decimal，不用浮點數。
• 對帳：每天把自己的勝標紀錄與 exchange 提供的報告比對，差異超過門檻要告警與人工處理。
• 反作弊：異常點擊率、同 IP 大量點擊、資料中心 IP、點擊時間過短等規則與模型（可另開題目）。

瓶頸與取捨

面試官可能的追問

情境題 3：設計 Chatbot 平台 高頻 深入

題目（Appier 真題）：「設計一個 chatbot。」以 MarTech 平台常見情境，建議把它定義成多租戶 chatbot 平台：品牌客戶在後台設定對話流程與知識庫，終端使用者透過 LINE、Facebook Messenger、網站聊天視窗與機器人對話，必要時轉真人客服。核心難點：多渠道接入、對話順序、狀態管理、LLM 的延遲與成本、人工轉接。

需求釐清

估算

• 入站訊息：10⁷ ÷ 86,400 ≈ 116/s，峰值約 1,200/s。對 API 層不算大，瓶頸在 LLM。
• 假設 30% 訊息需要 LLM，峰值約 360 次/s；每次 2–5 秒 → 依 Little's Law（並發數 = 到達率 × 平均處理時間），同時在途請求約 700–1,800 個 → worker 必須是非同步 IO（asyncio / goroutine），不能每個請求佔一條執行緒阻塞等待。
• Token 成本：每次約 1,500 tokens（含檢索內容）× 每日約 300 萬次 ≈ 45 億 tokens/天，成本相當可觀 → 分層路由、快取、限制上下文長度。
• 儲存：每則訊息約 1 KB → 每日約 10 GB，保留一年約 3.6 TB。

API 設計

POST /webhooks/line/{channel_id}          # LINE 平台呼叫；驗證 X-Line-Signature
POST /webhooks/messenger/{page_id}        # Messenger 呼叫；驗證 X-Hub-Signature-256
GET  /webhooks/messenger/{page_id}        # Messenger 訂閱驗證（hub.challenge）
GET  /ws/chat?widget_key=...&session=...  # Web 聊天視窗 WebSocket

# 內部 / 客服後台
POST /v1/conversations/{id}/handoff       {"reason": "user_request"}
POST /v1/conversations/{id}/messages      {"text": "...", "agent_id": "a-9"}   # 客服回覆
POST /v1/conversations/{id}/release       # 客服結束，交還 bot
GET  /v1/conversations?tenant=..&state=WAITING_AGENT
GET  /ws/agent                             # 客服後台 WebSocket（即時新訊息）

資料模型

高層架構

深入 1：Webhook 接入、驗簽與非同步回覆

• 驗簽：LINE 以 channel secret 對 request body 做 HMAC-SHA256 再 Base64，放在 X-Line-Signature；Messenger 用 app secret 計算 X-Hub-Signature-256。必須用原始 body bytes 計算，並用常數時間比較（hmac.compare_digest）。
• 立即回 200：gateway 只做驗簽、正規化、寫入 Kafka，絕不在 webhook 請求中呼叫 LLM。否則 LLM 一慢，平台判定逾時而重送，形成重複處理甚至被停用。
• 正規化：把各渠道格式轉成內部統一的 InboundMessage（tenant_id、conversation_id、event_id、type、text、payload、timestamp），bot 邏輯只認內部格式，新增渠道只要寫 adapter。
• 回覆方式：LINE 的 reply API 使用 webhook 事件附帶的 reply token（一次性、有時效）；超過時效或需多次回覆時改用 push API（通常會計入訊息額度）。Messenger 有 24 小時標準訊息視窗的政策限制。這些渠道規則要封裝在 sender adapter 內。

import base64, hashlib, hmac, json
from fastapi import FastAPI, HTTPException, Request, Response

app = FastAPI()

def verify_line_signature(channel_secret: str, body: bytes, signature: str) -> bool:
    digest = hmac.new(channel_secret.encode(), body, hashlib.sha256).digest()
    return hmac.compare_digest(base64.b64encode(digest).decode(), signature)

@app.post("/webhooks/line/{channel_id}")
async def line_webhook(channel_id: str, request: Request):
    body = await request.body()                           # 必須用原始 bytes 驗簽
    channel = await channel_cache.get(channel_id)         # tenant、secret；本地快取
    if channel is None or not verify_line_signature(
            channel.secret, body, request.headers.get("x-line-signature", "")):
        raise HTTPException(401)
    for ev in json.loads(body).get("events", []):
        user_id = ev.get("source", {}).get("userId", "unknown")
        conv_id = f"{channel.tenant_id}:line:{channel_id}:{user_id}"
        msg = {
            "event_id": ev.get("webhookEventId"),         # 平台提供的事件 id，用來去重
            "conversation_id": conv_id,
            "tenant_id": channel.tenant_id,
            "type": ev.get("type"),
            "text": ev.get("message", {}).get("text"),
            "reply_token": ev.get("replyToken"),
            "ts": ev.get("timestamp"),
        }
        # key = conversation_id：同一對話進同一 partition，保證順序
        await producer.send_and_wait("chat.inbound", json.dumps(msg).encode(),
                                     key=conv_id.encode())
    return Response(status_code=200)

深入 2：訊息順序與 head-of-line blocking

使用者常連續傳好幾則短訊息（「你好」「我想問」「訂單 123 到哪了」）。若平行處理，可能先回第三則再回第一則，甚至用不完整的上下文回答。解法：以 conversation_id 為 Kafka partition key，同一對話的訊息進同一 partition，由同一個 consumer 依序處理。

但這帶來新問題：一個 partition 內有成千上萬個對話，如果 worker 嚴格逐筆處理，一個 LLM 呼叫卡 5 秒，同 partition 的其他對話全部排隊（head-of-line blocking）。進階做法：

• Keyed executor：worker 從 partition 拉訊息後，依 conversation_id 分派到各自的記憶體佇列，「不同對話並行、同一對話序列」。offset 只能 commit 到「最小的尚未完成 offset」，避免崩潰時遺失。
• Debounce 合併：收到訊息後等待短暫時間（例如 1–2 秒），把連續訊息合併成一次 LLM 呼叫，減少成本也讓回答更完整。
• 取消重算：LLM 尚在生成時新訊息到達，可取消舊請求、用合併後的上下文重新生成（成本較高但體驗較好）。
• 出站順序：outbound 也以 conversation_id 分區，sender 依序送出；每則訊息帶 seq，Web 端依 seq 排序顯示。

深入 3：對話狀態管理與人工轉接

• 狀態存放：conversation 文件存 state、slots、近期訊息摘要、version；熱資料快取在 Redis（TTL 例如 30 分鐘），寫入時用樂觀鎖（version 比對）避免 bot 與客服同時修改造成覆蓋。
• 上下文長度：LLM 不能塞入完整歷史；保留最近 N 輪 + 滾動摘要（summary），並把關鍵 slot 結構化存放。
• 轉人工觸發：使用者明確要求、NLU 信心低於門檻連續兩次、負面情緒、VIP 客戶、特定意圖（退款、客訴）。
• 分派：Agent router 依技能標籤、語言、目前負載（每位客服並發上限）分派；沒有可用客服時進入佇列並告知預估等待時間，逾時改為留言單。
• 即時推送給客服：客服後台透過 WebSocket 連到 Agent WS Gateway；gateway 有多台，用 Redis pub/sub 或 Kafka 依 agent_id 路由訊息到對應連線所在的節點。
• AGENT 狀態時 bot 靜默：worker 收到訊息只轉發給客服；可提供「建議回覆」給客服（AI 輔助），但不直接送給使用者。

import asyncio

LLM_TIMEOUT = 8

async def handle_inbound(msg):
    conv = await store.load(msg["conversation_id"])        # Redis 優先，miss 時讀 DB
    if msg["event_id"] in conv.recent_event_ids:          # 去重紀錄與狀態一起持久化，重播安全
        return
    conv.recent_event_ids.append(msg["event_id"])
    conv.recent_event_ids = conv.recent_event_ids[-50:]
    await store.append_message(conv.id, msg)

    if conv.state in ("AGENT", "WAITING_AGENT"):
        await agent_bus.publish(conv.assigned_agent, conv.id, msg)   # bot 不回覆
    else:
        reply = await route_and_answer(conv, msg)
        if reply.handoff:
            conv.state = "WAITING_AGENT"
            await agent_router.enqueue(conv)
        await outbound.send(conv.id, reply.messages, reply_token=msg.get("reply_token"))
    await store.save(conv, expected_version=conv.version) # 樂觀鎖；衝突時重新載入再處理

async def route_and_answer(conv, msg):
    if (flow_reply := flow_engine.match(conv, msg)) is not None:  # 1) 規則 / 按鈕：最快最便宜
        return flow_reply
    intent = await nlu.classify(msg["text"])                       # 2) 小模型意圖辨識
    if intent.confidence > 0.85 and intent.name in conv.bot.faq:
        return conv.bot.faq[intent.name]
    if not await llm_quota.try_consume(conv.tenant_id):            # 3) 租戶 LLM 配額
        return Reply.handoff_or_default()
    try:
        return await asyncio.wait_for(llm_orchestrator.answer(conv, msg), LLM_TIMEOUT)
    except asyncio.TimeoutError:
        return Reply.text("目前查詢人數較多，我幫你轉給專人處理", handoff=True)

深入 4：NLU/LLM 呼叫的延遲與成本

深入 5：速率限制

• 入站：每租戶、每使用者限流，防止惡意洗訊息耗盡 LLM 配額（例如每使用者每分鐘 20 則）。
• 出站：各渠道 API 有速率上限；sender 以每個 channel 帳號為單位做 token bucket（Redis 分散式），收到 429 時退避並降低速率。
• LLM provider：全域 RPM/TPM 限制，用集中式的限流器 + 優先順序（付費方案租戶優先）。

面試官可能的追問

情境題 4：LINE / 推播訊息大量發送系統 高頻 進階

題目（Appier take-home 延伸）：take-home 要求「合併兩個 JSON 檔 + 設計發送 LINE 訊息的 API」，面試時常延伸成：「行銷人員要對 1,000 萬名會員發送個人化 LINE 訊息，怎麼設計？」這是 MarTech 推播平台的核心：分眾、排程、扇出（fan-out）、上游限流、重試、去重、追蹤。

需求釐清

估算

• 1,000 萬人 ÷ 1,800 秒 ≈ 5,600 則/s。
• 若內容相同、可用 LINE multicast（一次最多 500 位收件者）：約 20,000 個請求，每秒約 11 個請求即可。
• 若內容個人化（每人不同），每人一個 push 請求 → 5,600 req/s，很可能超過上游限制 → 系統必須以上游限制為準排程，並回報預估完成時間；或把「內容相同的人」分組後用 multicast。
• 發送紀錄：1 億則/天 × 約 200 bytes ≈ 20 GB/天。
• 回流：發送後數分鐘內點擊湧入，tracker 要能承受尖峰（例如 1,000 萬 × 5% 點擊在 10 分鐘內 ≈ 830/s，峰值更高）。

API 設計（take-home 會考的部分）

# 單筆 / 交易型：非同步，回 202 + message_id；Idempotency-Key 防止 client 重試造成重複
POST /v1/messages
Idempotency-Key: 6f1c...-order-123-shipped
{"channel": "line", "to": {"user_id": "u-1"}, "template_id": "order_shipped",
 "variables": {"order_id": "123"}, "priority": "high"}
→ 202 {"message_id": "msg_88", "status": "queued"}

GET /v1/messages/msg_88 → {"status": "sent", "sent_at": "...", "provider_request_id": "..."}

# 大量 / 行銷 campaign
POST /v1/campaigns
{"name": "雙11預熱", "segment_id": "seg_cart_abandon_30d", "channel": "line",
 "template_id": "promo_1111", "schedule": {"type": "at", "time": "2026-11-10T20:00:00+08:00"},
 "throttle_per_sec": 3000, "respect_quiet_hours": true}
→ 201 {"campaign_id": "cmp_7", "status": "SCHEDULED", "estimated_recipients": 8423110}

POST /v1/campaigns/cmp_7:pause    POST /v1/campaigns/cmp_7:resume    POST /v1/campaigns/cmp_7:cancel
GET  /v1/campaigns/cmp_7/stats → {"targeted": 8423110, "sent": 5120033, "failed": 2310,
                                  "skipped_unsubscribed": 40211, "clicked": 120334, "eta": "..."}

資料模型

高層架構

深入 1：分眾快照與排程

• 名單快照：在發送開始時把 segment 解析成固定名單（user_id 列表寫到 S3），之後所有 batch 都基於這份快照。好處：進度可計算、暫停/續傳可定位、重跑不會因分群資料變動而發給不同的人。
• 排程器：多個 scheduler 實例以 DB 鎖領取到期 campaign，避免重複觸發：

-- MySQL 8 / PostgreSQL：多實例同時執行也不會領到同一個 campaign
START TRANSACTION;
SELECT id FROM campaigns
WHERE status = 'SCHEDULED' AND scheduled_at <= NOW()
ORDER BY scheduled_at
LIMIT 10
FOR UPDATE SKIP LOCKED;
-- 對選到的 id：
UPDATE campaigns SET status = 'RUNNING', started_at = NOW()
WHERE id IN (/* 上面選到的 id */) AND status = 'SCHEDULED';
COMMIT;

• 依使用者時區發送（「每個人當地晚上 8 點」）：把名單依時區分組，產生多個子排程。
• 勿擾時段與頻次：fan-out 時過濾；被勿擾時段擋下的可延後到允許時段，而不是直接丟棄（依 campaign 設定）。
• 大名單扇出：fan-out worker 讀取快照，以 500 人一組（配合 multicast 上限）或每人一則產生 batch，寫入 send_batches 與 Kafka；本身也要可續傳（記錄已處理到快照的哪個位置）。

深入 2：上游 rate limit 與優先級

• 全域限流：上游限制是針對「整個 channel 帳號」的，但 sender 有很多台，所以限流器必須是分散式的：Redis token bucket（Lua 原子操作，見經典題：rate limiter），或由協調者把總速率平均分配給各 worker（各自本地限流，worker 數變動時重新分配）。
• 自適應：收到 429 時採 AIMD（加法增、乘法減）：立即把速率減半，之後慢慢加回，類似 TCP 擁塞控制。尊重 Retry-After。
• 優先級隔離：交易型與行銷型分開 topic 與 worker pool，或在 token bucket 中保留一部分額度給高優先級，避免 1,000 萬則行銷訊息堵住 OTP。
• 多租戶公平性：同一平台上多個品牌各自有自己的 LINE 帳號與限額；共用的 worker 要避免大客戶 campaign 佔滿所有 worker → 依 tenant 分 partition 或 weighted fair queuing。

深入 3：重試、去重與「不確定結果」

去重的三道防線：(1) API 層 Idempotency-Key；(2) 系統內 (campaign_id, user_id) 唯一鍵：發送前寫入 deliveries 狀態為 SENDING（條件寫入，已存在就跳過）；(3) 對上游使用 retry key：LINE Messaging API 的 push/multicast 等端點支援 X-Line-Retry-Key header（UUID），在有效期間內用同一個 key 重送不會重複發送，若該 key 已被接受會回 409。retry key 必須在建立 batch 時產生並持久化，而不是每次重試才產生，否則失去意義。

import asyncio, random
import aiohttp

MULTICAST_URL = "https://api.line.me/v2/bot/message/multicast"
MAX_ATTEMPTS = 6

async def send_batch(session, limiter, account, batch):
    """batch: {"batch_id", "user_ids" (最多 500), "messages", "retry_key"(建立 batch 時產生)}"""
    for attempt in range(MAX_ATTEMPTS):
        await limiter.acquire(account.id)                       # 分散式 token bucket
        try:
            async with session.post(
                MULTICAST_URL,
                json={"to": batch["user_ids"], "messages": batch["messages"]},
                headers={"Authorization": f"Bearer {account.access_token}",
                         "X-Line-Retry-Key": batch["retry_key"]},
                timeout=aiohttp.ClientTimeout(total=10),
            ) as resp:
                status = resp.status
                retry_after = float(resp.headers.get("Retry-After", 0))
        except (aiohttp.ClientError, asyncio.TimeoutError):
            status, retry_after = None, 0                       # 結果不確定 → 用同一 retry key 重送

        if status in (200, 409):                                # 409：此 retry key 已被接受過
            return await mark_batch(batch, "SENT")
        if status == 429:
            limiter.decrease(account.id)                        # AIMD：速率減半
        elif status is not None and 400 <= status < 500:
            return await mark_batch(batch, "FAILED", f"http {status}")   # 不可重試
        backoff = random.uniform(0, min(60, 2 ** attempt))      # full jitter
        await asyncio.sleep(max(backoff, retry_after))
    await dead_letter.put(batch)                                # 重試耗盡：人工 / 稍後重放

深入 4：送達與開啟追蹤

• 送出（sent）：上游 API 回 200 即記錄，並保存上游回傳的 request id 以便追查。
• 送達 / 開啟：各渠道能力不同。App push 可由 SDK 回報「收到」與「開啟」事件（走情境題 1 的事件管線）；Email 常用追蹤像素（但會受隱私保護機制影響，數字偏高或不準）；LINE 等平台通常提供彙總層級的統計 API，而非逐人送達回條，所以實務上以點擊追蹤為主。
• 點擊追蹤：訊息中的連結替換成短網址/轉址服務（https://trk.example.com/c/abc123），轉址時記錄 campaign、user、時間後 302 到原始網址；短碼內含簽章避免竄改。
• 轉換歸因：點擊後一段時間內的購買事件，依歸因規則（例如 7 天內最後點擊）記到 campaign。

面試官可能的追問

情境題 5：合併多來源使用者資料（Identity / Profile 整合） 高頻 深入

題目來源：Appier coding 題「合併兩個 List[dict] 中相同 id 的資料」與追問「兩份資料如何 merge？資料量到上億筆怎麼辦？」放大後就是 MarTech 平台的核心元件：Customer Data Platform（CDP）的身分解析（identity resolution）與統一使用者輪廓（unified profile）。面試時可以從 coding 題一路延伸到系統設計，展現「從演算法到分散式」的連貫思考。

需求釐清

估算

• ID 對應表：3 億 × 約 100 bytes ≈ 30 GB → 分散式 KV，或 Redis Cluster 全放記憶體。
• Profile：1 億 × 約 2 KB ≈ 200 GB → 分散式 KV（DynamoDB、Cassandra、ScyllaDB、HBase），熱資料加 cache。
• 原始來源資料：每日全量或增量檔數十到數百 GB → 存 S3，Spark 處理。
• 批次 join：上億筆 × 多來源 → 單機記憶體放不下，需要依 id 分區的分散式處理。

從 coding 題開始：合併兩個 List[dict]

面試的 coding 版本通常是：給兩個 list，每個元素是含 id 的 dict，把相同 id 的資料合併。先講清楚衝突規則再寫程式（這本身就是加分）：誰覆蓋誰？空值怎麼辦？陣列欄位要合併還是取代？

from typing import Any

MULTI_VALUED = {"tags", "emails"}          # 多值欄位：取聯集

def merge_two(old: dict, new: dict) -> dict:
    """以 updated_at 較新的為主；空值不覆蓋；多值欄位取聯集。"""
    if new.get("updated_at", "") >= old.get("updated_at", ""):
        newer, older = new, old
    else:
        newer, older = old, new
    out = dict(older)
    for field, value in newer.items():
        if field in MULTI_VALUED:
            out[field] = sorted(set(older.get(field) or []) | set(value or []))
        elif value not in (None, ""):
            out[field] = value               # 較新且非空才覆蓋
    return out

def merge_lists(a: list[dict], b: list[dict], key: str = "id") -> list[dict]:
    merged: dict[Any, dict] = {}             # 保持插入順序（Python 3.7+ dict 有序）
    for rec in (*a, *b):
        k = rec.get(key)
        if k is None:
            continue                         # 無 id 的資料：記錄後另外處理，不要默默丟掉
        merged[k] = merge_two(merged[k], rec) if k in merged else dict(rec)
    return list(merged.values())

a = [{"id": 1, "name": "Amy", "email": None, "tags": ["vip"], "updated_at": "2026-10-01"}]
b = [{"id": 1, "name": "Amy Lin", "email": "amy@x.com", "tags": ["line"], "updated_at": "2026-10-05"},
     {"id": 2, "name": "Bob", "updated_at": "2026-09-01"}]
print(merge_lists(a, b))
# [{'id': 1, 'name': 'Amy Lin', 'email': 'amy@x.com', 'tags': ['line', 'vip'], 'updated_at': '2026-10-05'},
#  {'id': 2, 'name': 'Bob', 'updated_at': '2026-09-01'}]

複雜度：時間 O(n + m)（假設每筆欄位數為常數），空間 O(n + m)。追問「同一個 list 內 id 重複怎麼辦」：上面的寫法自然處理（同樣走 merge_two）。追問「保持 a 的順序」：dict 保留插入順序，a 的 id 會先出現。

追問：資料量到上億筆怎麼辦？

import json, zlib

def bucket_of(record_id, n):
    # 不要用內建 hash()：字串的 hash 每個 process 隨機（PYTHONHASHSEED），跨程序不穩定
    return zlib.crc32(str(record_id).encode()) % n

def split_into_buckets(path, out_dir, tag, n):
    outs = [open(f"{out_dir}/{tag}-{i}.jsonl", "w", encoding="utf-8") for i in range(n)]
    try:
        with open(path, encoding="utf-8") as f:
            for line in f:                                 # 串流讀取，不整檔載入
                outs[bucket_of(json.loads(line)["id"], n)].write(line)
    finally:
        for fh in outs:
            fh.close()

def merge_buckets(out_dir, n, out_path):
    with open(out_path, "w", encoding="utf-8") as out:
        for i in range(n):                                 # 每次只有一個桶在記憶體中
            merged = {}
            for tag in ("a", "b"):
                with open(f"{out_dir}/{tag}-{i}.jsonl", encoding="utf-8") as f:
                    for line in f:
                        rec = json.loads(line)
                        k = rec["id"]
                        merged[k] = merge_two(merged[k], rec) if k in merged else rec
            for rec in merged.values():
                out.write(json.dumps(rec, ensure_ascii=False) + "\n")

# PySpark 版本：每個欄位取「最新且非空」的值（max_by 需 Spark 3.3+）
from pyspark.sql import SparkSession, functions as F

spark = SparkSession.builder.appName("profile-merge").getOrCreate()
crm = spark.read.parquet("s3://lake/crm/dt=2026-11-03/").withColumn("src", F.lit("crm"))
app = spark.read.parquet("s3://lake/app/dt=2026-11-03/").withColumn("src", F.lit("app"))
rows = crm.unionByName(app, allowMissingColumns=True)

fields = [c for c in rows.columns if c not in ("id", "updated_at", "src")]
merged = rows.groupBy("id").agg(
    # 值為 null 時排序鍵設為 null → 不會被選中，等同「非空值中最新的那個」
    *[F.max_by(F.col(c), F.when(F.col(c).isNotNull(), F.col("updated_at"))).alias(c)
      for c in fields],
    F.max("updated_at").alias("updated_at"),
)
merged.write.mode("overwrite").parquet("s3://lake/profile_merged/dt=2026-11-03/")

身分解析：Identity Graph 與 Union-Find

真實情況不是「兩份資料有相同的 id」，而是每個來源有不同的識別碼：CRM 有 email + 會員編號；App 登入後有 user_id + device_id；Web 登入後 cookie 與 user_id 綁定。把每個識別碼當成圖的節點，「同一筆紀錄中同時出現」就連一條邊，一個連通分量（connected component）就是一個人。

上圖有兩個連通分量：左邊 7 個識別碼屬於同一人（Amy），右邊兩個屬於另一個尚未登入的匿名使用者。

class UnionFind:
    def __init__(self):
        self.parent, self.size = {}, {}

    def find(self, x):
        if x not in self.parent:
            self.parent[x], self.size[x] = x, 1
        root = x
        while self.parent[root] != root:
            root = self.parent[root]
        while self.parent[x] != root:                 # 路徑壓縮
            self.parent[x], x = root, self.parent[x]
        return root

    def union(self, a, b):
        ra, rb = self.find(a), self.find(b)
        if ra == rb:
            return ra
        if self.size[ra] < self.size[rb]:            # union by size，樹高 O(log n)
            ra, rb = rb, ra
        self.parent[rb] = ra
        self.size[ra] += self.size[rb]
        return ra

def resolve(records, max_degree=50):
    """records: 每筆是一個來源紀錄中同時出現的識別碼，例如 {"email": ..., "device": ...}"""
    degree = {}
    for r in records:
        for k, v in r.items():
            if v:
                degree[(k, v)] = degree.get((k, v), 0) + 1
    uf = UnionFind()
    for r in records:
        ids = [(k, v) for k, v in r.items() if v and degree[(k, v)] <= max_degree]  # 排除超級節點
        for other in ids[1:]:
            uf.union(ids[0], other)
        if ids:
            uf.find(ids[0])
    groups = {}
    for node in uf.parent:
        groups.setdefault(uf.find(node), []).append(node)
    return list(groups.values())

• 超級節點（super node）：共用裝置（網咖電腦）、測試帳號（test@test.com）、預設值（電話 0000000000）會把成千上萬人串成一個分量。對策：度數上限、黑名單、只信任特定類型的邊（例如 email 邊比 IP 邊可靠）。上面程式中的 max_degree 是度數上限的簡化版（實務上通常依識別碼類型分別設定）。
• 確定性 vs 機率性比對：確定性（相同的雜湊 email、登入綁定）準確；機率性（相同 IP + 相似裝置指紋）覆蓋率高但會誤合併。預設只用確定性規則，機率性結果另存且標記信心分數，供廣告受眾擴展等容錯度高的場景使用。
• 分散式連通分量：上億節點時用 Spark GraphFrames 的 connected components，或自行實作迭代式 label propagation（每輪每個節點取鄰居的最小 label，直到不再變化）。
• 正規化：email 轉小寫並去空白、電話轉 E.164 格式、再做 SHA-256 雜湊；正規化不一致會造成漏合併。

屬性衝突規則

每個欄位保留 provenance（值來自哪個來源、何時更新），方便除錯與向客戶解釋「為什麼這個人的生日是這個」。規則要可設定（每個租戶不同），以設定檔驅動合併引擎，而不是寫死在程式碼。

API 與資料模型

GET  /v1/profiles:lookup?id_type=email_sha256&id_value=9f86d0...   → 200 {"unified_id": "P123", "profile": {...}}
GET  /v1/profiles/P123
POST /v1/profiles:batchGet          {"unified_ids": ["P1", "P2", ...]}       # 推播 fan-out 時批次查
POST /v1/identities:link            {"ids": [{"type": "user_id", "value": "u-9"},
                                              {"type": "device_id", "value": "iPhone-A"}],
                                     "source": "app_login", "observed_at": "..."}
DELETE /v1/profiles/P123            # 隱私刪除：非同步，回 202 + 追蹤 id

高層架構：離線批次 + 線上增量

• 離線全量：每天從 S3 重算完整 identity graph 與 profile，結果寫入新版本的表，驗證後原子切換（版本指標或表別名）。全量重算能修正增量路徑累積的錯誤，也是規則變更後的回補方式。
• 線上增量：使用者登入時產生 link 事件 → Flink 查兩個識別碼目前的 unified_id：都沒有 → 建立新的；一個有 → 把另一個加入；兩個不同 → 合併兩個 profile（保留較舊的 unified_id 作為存活者，另一個寫入 id_alias，更新 id_map，屬性依規則合併）。同一個 unified_id 的更新依 key 分區序列化，避免併發寫入衝突。
• 批次與串流的銜接：快照代表時間點 T 的狀態；切換後，Flink 從 T 之前一點的 offset 重新套用增量事件（操作要冪等），確保快照之後的變更不遺失。
• 穩定 ID：每天重算時，新的連通分量要盡量沿用昨天的 unified_id（例如取分量中最舊的 unified_id），否則下游（推播紀錄、受眾名單）會全部對不上。

面試官可能的追問

經典題精簡版 高頻 進階

以下九題是系統設計面試的「基本功」，Appier 的情境題常以它們為零件（例如推播需要 rate limiter 與 unique ID、報表需要分散式快取）。每題只列出核心需求、關鍵設計與最常被追問的點。

1. URL Shortener（短網址）

需求：長網址 → 短碼；短碼轉址；可選自訂短碼、過期時間、點擊統計。估算：每月 1 億個新短網址（約 40/s 寫入），讀寫比 100:1（約 4,000/s 讀，峰值數倍）；5 年 60 億筆。Base62 7 碼可表示 62⁷ ≈ 3.5 兆個，足夠。每筆約 500 bytes → 5 年約 3 TB。

• 短碼產生：(a) 全域唯一數字 ID → Base62 編碼（無碰撞，但連續 ID 可被猜測，可先做可逆的位元混淆）；(b) 對長網址做雜湊取前 7 碼（需檢查碰撞、重試加鹽）；(c) 預先產生短碼池。面試推薦 (a) + 號段發號（每台服務一次向 DB 取 1,000 個 ID 區間）。
• 301 vs 302：301 永久轉址會被瀏覽器快取，降低伺服器負載但無法統計每次點擊；需要統計時用 302。
• 讀多：cache-aside + Redis，熱門短碼命中率高；不存在的短碼要快取空結果或用 Bloom filter 擋（cache penetration）。
• 同一長網址是否回同一短碼：需要 long_url → code 的反向索引（雜湊後索引），依需求決定。

ALPHABET = "0123456789abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ"

def encode62(n: int) -> str:
    if n == 0:
        return ALPHABET[0]
    out = []
    while n:
        n, r = divmod(n, 62)
        out.append(ALPHABET[r])
    return "".join(reversed(out))

def decode62(s: str) -> int:
    n = 0
    for ch in s:
        n = n * 62 + ALPHABET.index(ch)
    return n

assert decode62(encode62(3_521_614_606_207)) == 3_521_614_606_207   # 62**7 - 1 → "ZZZZZZZ"

2. 分散式 Rate Limiter（Redis + Lua）

分散式的關鍵是「讀取 → 計算 → 寫回」必須原子，否則多台 gateway 同時讀到相同 token 數會超賣。Redis 執行 Lua 腳本時不會穿插其他命令，因此天然原子：

import redis

r = redis.Redis()

TOKEN_BUCKET = r.register_script("""
local key       = KEYS[1]
local rate      = tonumber(ARGV[1])      -- 每秒補充幾個 token
local capacity  = tonumber(ARGV[2])      -- bucket 容量（允許的突發量）
local requested = tonumber(ARGV[3])
local t   = redis.call('TIME')           -- 用 Redis 伺服器時間，避免各 client 時鐘不一致
local now = tonumber(t[1]) * 1000 + math.floor(tonumber(t[2]) / 1000)
local data   = redis.call('HMGET', key, 'tokens', 'ts')
local tokens = tonumber(data[1]) or capacity
local ts     = tonumber(data[2]) or now
tokens = math.min(capacity, tokens + (now - ts) / 1000 * rate)
local allowed = 0
if tokens >= requested then
  tokens  = tokens - requested
  allowed = 1
end
redis.call('HSET', key, 'tokens', tokens, 'ts', now)
redis.call('PEXPIRE', key, math.ceil(capacity / rate * 1000) + 1000)
return allowed
""")

def allow(client_id: str, rate: float = 10, capacity: int = 20, cost: int = 1) -> bool:
    try:
        return TOKEN_BUCKET(keys=[f"rl:{{{client_id}}}"], args=[rate, capacity, cost]) == 1
    except redis.RedisError:
        return True     # fail-open：限流器故障時放行（保護性限流可改為 fail-closed）

• 放在哪：API gateway / Nginx / Envoy（全域）+ 服務內（細粒度，例如每租戶每功能）。
• 回應：429 + Retry-After，常見還會回 X-RateLimit-Limit、X-RateLimit-Remaining。
• 效能：每個請求一次 Redis 往返；超高 QPS 時可用「本地 token bucket + 定期向 Redis 申請配額」的混合方案（與廣告預算租約同一思路），犧牲少量精確度換延遲。
• Redis Cluster：key 用 hash tag {client_id}，確保腳本存取的 key 在同一 slot。

3. 分散式 Unique ID

Snowflake 結構：1 bit 符號 + 41 bit 毫秒時間戳（約 69 年）+ 10 bit 機器 ID（1,024 台）+ 12 bit 序號（每毫秒 4,096 個）。

import threading, time

EPOCH_MS = 1_704_067_200_000                 # 自訂起點 2024-01-01 UTC，延長可用年限
WORKER_BITS, SEQ_BITS = 10, 12
MAX_WORKER = (1 << WORKER_BITS) - 1
MAX_SEQ = (1 << SEQ_BITS) - 1

class Snowflake:
    def __init__(self, worker_id: int):
        if not 0 <= worker_id <= MAX_WORKER:
            raise ValueError("worker_id out of range")
        self.worker_id, self.last_ms, self.seq = worker_id, -1, 0
        self.lock = threading.Lock()

    def next_id(self) -> int:
        with self.lock:
            now = int(time.time() * 1000)
            if now < self.last_ms:
                raise RuntimeError("clock moved backwards")   # 小幅回撥可等待追上
            if now == self.last_ms:
                self.seq = (self.seq + 1) & MAX_SEQ
                if self.seq == 0:                            # 本毫秒 4096 個已用完
                    while now <= self.last_ms:
                        now = int(time.time() * 1000)
            else:
                self.seq = 0
            self.last_ms = now
            return ((now - EPOCH_MS) << (WORKER_BITS + SEQ_BITS)) | (self.worker_id << SEQ_BITS) | self.seq

追問：worker id 怎麼分配？（K8s 中可用 StatefulSet 序號、或啟動時向 ZooKeeper/etcd/Redis 註冊租約）；時鐘回撥怎麼辦？（NTP 只做緩慢調整（slew）、偵測到回撥時等待或拒絕服務、保留備用 worker id）。

4. News Feed / 推薦結果服務

經典 news feed 的核心取捨是 fan-out 時機：

Appier 版本：推薦結果服務（例如電商「為你推薦」）。模式是「離線預計算 + 線上即時調整」：

• 召回（candidate generation）離線做，排序（ranking）線上做，兼顧品質與延遲。
• 過濾必須即時：缺貨、已購買、價格變動不能等明天的批次。
• 冷啟動與失敗時的 fallback：熱門、同類別熱銷。
• A/B 測試：依 user hash 分流，記錄每次曝光使用的模型版本以便歸因。

5. 即時排行榜

Redis Sorted Set（底層為 skiplist + hash table）：ZINCRBY 更新分數、ZREVRANGE 取前 N 名、ZREVRANK 查名次，皆為 O(log N)（取範圍為 O(log N + M)）。

import redis
r = redis.Redis()

def add_score(board: str, user: str, delta: float):
    r.zincrby(board, delta, user)

def top_n(board: str, n: int = 10):
    return r.zrevrange(board, 0, n - 1, withscores=True)

def my_rank(board: str, user: str):
    rank = r.zrevrank(board, user)
    return None if rank is None else rank + 1          # 0-based → 1-based

def around_me(board: str, user: str, k: int = 5):
    rank = r.zrevrank(board, user)
    if rank is None:
        return []
    return r.zrevrange(board, max(0, rank - k), rank + k, withscores=True)

# 每日榜：key 帶日期並設 TTL，例如 board:2026-11-03，週榜可用 ZUNIONSTORE 合併 7 天

• 同分排序：把分數編碼成 score * 10^k + (MAX_TS - ts)，先達到者排前面（注意 double 精度上限約 2⁵³）。
• 規模：單一 ZSET 存數千萬成員仍可運作，但單 key 成為熱點且無法分散；超大規模可依分數區間分片、或只對前 N 名精確排名，其餘給近似百分位。
• 持久化：分數的 source of truth 放 DB 或事件流，Redis 可由事件重建。

6. 通知系統

與情境題 4 的推播系統高度重疊，差異在於「通知」多為事件觸發、單一使用者的：

• 使用者偏好：每類通知每個渠道可開關、勿擾時段、語言。
• 合併摘要（digest）：「你有 12 則新留言」而不是 12 則推播；用延遲佇列聚合一段時間內的同類事件。
• 站內信：每使用者的通知清單（依 user_id 分區、時間排序）與未讀數（Redis 計數器）。
• 可靠性：冪等鍵（事件 id + 渠道）、重試、DLQ、供應商故障時切換備援供應商（例如 SMS 雙供應商）。

7. 分散式快取

設計一個類 Memcached/Redis Cluster 的分散式快取，核心問題：資料怎麼分布、節點增減怎麼辦、怎麼淘汰、怎麼確保可用。

import bisect, hashlib

class ConsistentHashRing:
    """一致性雜湊 + 虛擬節點：增減一個節點只影響約 1/N 的 key。"""

    def __init__(self, nodes=(), vnodes=150):
        self.vnodes = vnodes
        self.ring = []            # 排序後的 hash 值
        self.owner = {}           # hash 值 -> 實體節點
        for n in nodes:
            self.add(n)

    @staticmethod
    def _hash(key: str) -> int:
        return int.from_bytes(hashlib.md5(key.encode()).digest()[:8], "big")

    def add(self, node: str):
        for i in range(self.vnodes):           # 虛擬節點讓分布更平均
            h = self._hash(f"{node}#{i}")
            bisect.insort(self.ring, h)
            self.owner[h] = node

    def remove(self, node: str):
        for i in range(self.vnodes):
            h = self._hash(f"{node}#{i}")
            self.ring.remove(h)
            del self.owner[h]

    def get(self, key: str) -> str:
        idx = bisect.bisect(self.ring, self._hash(key)) % len(self.ring)   # 順時針第一個
        return self.owner[self.ring[idx]]

ring = ConsistentHashRing(["cache-a", "cache-b", "cache-c"])
print(ring.get("user:42"))

其他要點：淘汰策略（LRU、LFU、TTL）；複製（主從，主掛時提升從節點）；寫入策略（cache-aside 最常見、write-through、write-behind）。Redis Cluster 實際上用的是 16,384 個 hash slot 而非一致性雜湊環，但目的相同：節點增減只搬移部分資料。

8. Web Crawler

估算：每月抓 10 億頁 → 約 385 頁/s；平均每頁 100 KB → 每月約 100 TB 原始內容。

• 禮貌性（politeness）：每個網域一個佇列，同一網域同時只有一個連線並設間隔；遵守 robots.txt。
• 優先級：依 PageRank、更新頻率、網域重要性決定先抓哪些。
• 去重：URL 層用正規化 + Bloom filter（數十億 URL 也只需數 GB），內容層用 hash 精確去重、simhash 近似去重。
• 陷阱：無限生成的 URL（日曆頁）、spider trap → 限制深度與每網域頁數。
• 分散：依網域 hash 分配到 fetcher 節點，讓同網域的禮貌性控制在單一節點完成。

9. 檔案上傳 / 大檔分段上傳

原則：檔案不要經過應用伺服器。API 伺服器只負責授權與中繼資料，檔案本體由 client 透過預簽章 URL（presigned URL）直接上傳到物件儲存。

• S3 multipart upload：除最後一個 part 外每個 part 至少 5 MiB、最多 10,000 個 part；part 可平行上傳、失敗只重傳該 part。
• 續傳：client 記錄 upload_id，斷線後用 ListParts 查詢已完成的 part，只補傳缺少的。
• 完整性：每個 part 帶 checksum，完成後比對整體 checksum。
• 清理：未完成的 multipart upload 仍會佔用儲存費用，用 lifecycle rule 自動中止超過 N 天的上傳。
• 安全：presigned URL 設短效期、限制 content-type 與大小；上傳完成前檔案不可被公開存取；後處理（掃毒、轉檔）透過事件非同步完成。

系統設計常見追問 Q&A 彙整 高頻

不論題目是什麼，面試官的追問常落在下列幾類。每題都準備一段 1–2 分鐘的回答，並能連結到前面的情境題。

自我檢查表與延伸閱讀 基礎

面試中的自我檢查表

畫完架構後，用這張表快速掃一遍自己的設計，通常能找到面試官接下來要問的點：

練習方法

1. 每題限時 45 分鐘，計時並大聲講出來（或錄音），模擬真實面試。
2. 先畫出本章五個情境題的架構圖（不看筆記），再對照補漏。
3. 對每題準備「一句話總結」：例如報表系統 =「SDK 批次至少一次送達 → 無狀態 collector → Kafka → Flink 去重聚合 + S3 原始資料 → ClickHouse 預聚合 → 批次校正」。
4. 對每個元件練習回答「為什麼用它？拿掉會怎樣？替代方案是什麼？」。
5. 找朋友互相扮演面試官，專門追問故障與邊界情境。

推薦延伸閱讀

Designing Data-Intensive Applications（DDIA，Martin Kleppmann）

分散式資料系統的聖經：複製、分區、交易、一致性與共識、批次與串流處理。本章的 exactly-once、watermark、CDC、partitioning 都能在書中找到完整理論。強烈建議至少讀第 5–9 章與第 10–11 章。

System Design Interview – An Insider's Guide Vol. 1 / Vol. 2（Alex Xu 等）

Vol. 1 涵蓋 rate limiter、一致性雜湊、unique ID、URL shortener、web crawler、通知系統、news feed、chat 等；Vol. 2 有 ad click event aggregation（與本章情境題 1 高度相關）、即時排行榜、分散式 message queue、支付系統等。是面試題型的最佳練習本。

經典論文

Amazon Dynamo（最終一致 KV、一致性雜湊）、Google Bigtable、Kafka 原始論文、Google 的 The Dataflow Model（event time、watermark 的理論基礎）、The Tail at Scale（尾延遲與 hedged request）、HyperLogLog 原始論文與 Google 的 HyperLogLog in Practice、Yahoo 的 Indexing Boolean Expressions（廣告 targeting 索引）、Google 的 Ad Click Prediction: a View from the Trenches 與 Facebook 的 Practical Lessons from Predicting Clicks on Ads at Facebook（CTR 預估工程）。

公司工程部落格（類型）

大型網路公司（Netflix、Uber、LinkedIn、Pinterest、Airbnb、Discord、Cloudflare）的技術部落格常寫真實的擴展故事與事故檢討；AdTech/MarTech 公司的部落格可看 RTB、bidder、即時競價與資料管線的實務；雲端供應商（AWS Architecture Blog、Google Cloud Blog）的參考架構可學習託管服務的組合方式。面試前也建議搜尋 Appier 公開的技術分享與產品文件，了解其產品線（CrossX、AIQUA、AIXON、AIDEAL）的使用情境。

工具文件

Kafka、Flink、ClickHouse、Redis 官方文件中的「設計」或「架構」章節（例如 Flink 的 event time 與 watermark、ClickHouse 的 MergeTree 家族），比部落格文章更精確。

面試自測題