30 天終於來到最後一天。
前面 29 天，我們已經從最基本的：
Client → DNS → Server → Database
一路學到：
Load Balancer
SQL / NoSQL
Database Index
Cache
Replication
Sharding
CDN
Message Queue
Rate Limiter
Consistency
CAP Theorem
Reliability
Observability
Security
URL Shortener
Notification System
Chat System
YouTube
Uber
LLM
Embedding
Vector Database
RAG
AI Agent
Production AI Agent
AI SaaS
最後一天不再塞大量 Technology，而是把這些 Building Blocks
整理成一套真正可以帶進 System Design Interview 的思考 Framework。
核心問題只有一個：
面對一個從來沒看過的題目，你能不能從 Requirements 開始，逐步設計
Architecture、找到 Bottleneck、處理 Failure，最後清楚說明 Trade-offs？
Framework（框架）
一套可以重複使用的思考結構。
例如：
Design URL Shortener
Design Chat
Design YouTube
Design Uber
Design RAG
Design AI SaaS
題目不同，但可以共用：
Requirements
↓
Scale
↓
Entities
↓
API
↓
Data Model
↓
High-Level Architecture
↓
Critical Flow
↓
Bottleneck
↓
Scaling
↓
Consistency
↓
Reliability
↓
Security
↓
Observability
↓
Trade-offs
Framework 不是標準答案。
它的目的是讓你面對陌生題目時，知道：
下一步應該思考什麼？
看到 Chat System 就直接回答：
WebSocket
Kafka
Redis
Cassandra
不是好的 System Design。
真正應該能回答：
Why WebSocket?
Why Queue?
Why Cache?
Why this Database?
What problem does each component solve?
What trade-off does it introduce?
System Design 的核心不是：
Technology Name
而是：
Problem → Requirement → Decision → Trade-off
最後整理成 22 個 Steps：
Step 1 Clarify Requirements
Step 2 Define Scope
Step 3 Estimate Scale
Step 4 Identify Core Entities
Step 5 Design API
Step 6 Design Data Model
Step 7 Draw High-Level Architecture
Step 8 Walk Through Critical Flows
Step 9 Identify Bottlenecks
Step 10 Scale Application Layer
Step 11 Scale Data Layer
Step 12 Add Cache
Step 13 Add Async Processing
Step 14 Discuss Consistency
Step 15 Design Reliability
Step 16 Design Security
Step 17 Add Observability
Step 18 Handle Failure Scenarios
Step 19 Discuss Trade-offs
Step 20 Scale 10x
Step 21 Add AI-Specific Design if Needed
Step 22 Summarize the Design
不是每題都要機械式走完。
它是一份：
不要漏掉重要問題的 Checklist。
拿到題目後：
先不要畫 Architecture。
先問：
What exactly are we building?
例如：
Design YouTube.
這句其實非常模糊。
可能包含：
Video Upload
Playback
Live Streaming
Comments
Search
Recommendation
Ads
Creator Analytics
Ambiguity（模糊性 / 不明確性）
Requirement 有多種可能解讀，但目前資訊不足。
System Design 題目通常故意很 Broad。
所以第一個能力就是：
Clarify ambiguity
這兩個前面已詳細解釋，不再重複完整定義。
Functional：
What can users do?
Non-Functional：
Scale?
Latency?
Availability?
Consistency?
Durability?
Security?
例如 Chat：
Functional:
Send message
Receive message
Message history
Non-Functional:
Low latency
High availability
Durable messages
Reasonable ordering
Prioritization（優先順序安排）
決定哪些 Requirements 最重要。
例如：
Must Have:
Send message
Receive message
History
Nice to Have:
Typing indicator
Emoji reaction
Search
沒有它，核心 Product 就無法成立。
有會更好，但第一版不一定需要。
面試時間有限，所以：
先處理核心 User Flow。
Scope 前面已使用過。
例如 YouTube：
In Scope:
Upload
Transcoding
Playback
Out of Scope:
Ads
Comments
Recommendation
Live Streaming
Out of Scope（範圍之外）
今天明確不深入設計的部分。
這不是偷懶，而是控制問題範圍。
前面都已接觸。
題目沒提供資訊時，提出合理假設：
I'll assume we're designing video-on-demand rather than live streaming.
限制 Design Choice 的條件：
100M users
200ms latency target
EU data residency
Limited budget
Strong consistency for payment
Day 19 已詳細學過：
Back-of-the-Envelope Estimation
DAU
RPS
QPS
Peak Traffic
Storage
Bandwidth
所以這裡不重新教公式。
估算的目的不是展示數學，而是回答：
One server enough?
One database enough?
Need cache?
Need partitioning?
How much storage?
How much bandwidth?
System Design 通常更在乎：
Order of Magnitude
而不是小數點後的精確數字。
Entity（實體）
System 中需要被表示、儲存或管理的重要 Business Object。
Chat：
User
Conversation
Message
Membership
Uber：
Driver
Passenger
Ride
Location
AI SaaS：
Tenant
Workspace
User
Agent
Document
Task
UsageEvent
Relationship（關係）
不同 Entities 之間如何連結。
例如：
Organization
↓ has many
Workspaces
User
↓ sends many
Messages
找出 Entities 和 Relationships 後，會自然幫助我們設計：
API
Data Model
Ownership
Permissions
API 前面已詳細學過。
先問：
What does the Client need from Backend?
例如 URL Shortener：
POST /urls
GET /{short_code}
Chat History：
GET /conversations/{id}/messages
Real-Time Chat 則可能使用：
WebSocket
不要因為會 REST，就把所有 Communication 都硬設計成 REST。
逐字：
R = Representational = 表述性的 / 表示形式的
S = State = 狀態
T = Transfer = 傳輸
完整：
Representational State Transfer
= 表述性狀態傳遞
REST 是：
一種設計 Networked Applications / Web APIs 的 Architectural Style。
初學可以先理解成：
Client
↓ HTTP
Resource-oriented API
↓
Server
例如：
GET /users/123
POST /orders
DELETE /documents/456
REST 不是 HTTP 的另一個版本，也不是 Database。
Resource（資源）
REST Context：
API 想表示或操作的 Object / Concept。
例如：
/users/123
代表：
User 123
逐項：
C = Create = 建立
R = Read = 讀取
U = Update = 更新
D = Delete = 刪除
完整：
CRUD
= 建立、讀取、更新、刪除
常見 HTTP Mapping：
Create → POST
Read → GET
Update → PUT / PATCH
Delete → DELETE
這是常見慣例，不代表所有 API 必須完全如此。
通常表示：
對 Resource 做完整替換，或用完整 Representation 更新。
通常表示：
部分更新。
例如只改：
display_name
可以：
PATCH /users/123
先問：
What data must be persisted?
How is it accessed?
What are the relationships?
不要先問：
SQL or NoSQL?
應該先看：
Access Pattern
Relationships
Consistency
Scale
再選 Database。
Chat：
message
-------
message_id
conversation_id
sender_id
sequence_number
content
created_at
常見 Query：
Get messages for conversation X
ordered by sequence
所以可能建立：
Index:
(conversation_id, sequence_number)
這就是：
Access Pattern
→ Data Model
→ Index
不要一開始畫 30 個 Boxes。
先從：
Client
↓
Load Balancer / API Gateway
↓
Application Service
↓
Database
開始。
然後問：
What breaks first?
逐字：
H = High = 高階
L = Level = 層級
D = Design = 設計
完整：
High-Level Design
= 高階設計
HLD 描述：
System 的主要 Components，以及它們如何 Communication。
例如：
Client
↓
Load Balancer
↓
Application Servers
↓
Cache
↓
Database
逐字：
L = Low = 低階 / 細節層級
L = Level = 層級
D = Design = 設計
完整：
Low-Level Design
= 低階設計 / 詳細設計
LLD 更深入：
Classes
Interfaces
Objects
Methods
Design Patterns
HLD
→ System-level architecture
LLD
→ Component / class-level design
System Design Interview 通常偏 HLD，但有些公司會深入：
API
Schema
Concurrency
Class Design
Critical Flow（關鍵流程）
最重要、最能驗證 Architecture 是否合理的 End-to-End Flow。
Chat：
Alice sends message
↓
Server receives
↓
Persist
↓
Route
↓
Bob receives
↓
ACK
Happy Path（正常成功路徑）
所有主要 Components 正常時，Request 成功完成的流程。
先確認：
Normal system works
再處理 Failure。
Error Path（錯誤路徑）
某個 Component / Operation Failure 時的流程。
例如：
DB unavailable
Worker crashes
Provider timeout
Network failure
Bottleneck 前面已詳細介紹。
問：
What reaches capacity first?
可能：
Application CPU
Database Reads
Database Writes
Storage
Network
Queue
External API
GPU
Vector Search
不要看到 Scale 就把所有 Component 都加上。
先找：
Actual bottleneck
常見方式：
Stateless Application
+
Horizontal Scaling
+
Load Balancer
都已在前面詳細介紹。
例如：
Users
↓
Load Balancer
↓
App 1
App 2
App 3
不要直接：
Sharding!
可以依序問：
Can query/schema improve?
↓
Can index help?
↓
Can cache reduce reads?
↓
Can read replica help?
↓
Can partition help?
↓
Do we actually need sharding?
Query Optimization（查詢最佳化）
改善 Query、Execution Plan、Index 使用或 Data Access Strategy，降低
Latency 和 Resource Usage。
例如：
SELECT *
但其實只需要：
SELECT id, name
或 Query 缺少適合 Index。
Premature = 過早的
Optimization = 最佳化
完整：
Premature Optimization
= 過早最佳化
意思：
還沒有證據顯示某處是 Bottleneck，就先加入大量複雜 Optimization。
例如：
100 users
↓
Immediately create 64 DB shards
可能只增加：
Complexity
Failure Modes
Operational Cost
Cache 已詳細學過。
問：
What data is read frequently?
What changes slowly?
Can stale data be tolerated?
Cache 不是免費加速器。
它也會帶來：
Invalidation
Stale Data
Hot Key
Stampede
Memory Cost
Message Queue 已詳細學過。
最重要的問題：
Does this work need to finish before responding to the user?
如果不用：
Move it off the Critical Path
例如：
Email
Thumbnail
Analytics
Notification
Background AI Task
Consistency 和 CAP 已詳細學過。
不要只說：
Use eventual consistency.
要回答：
Which data?
Why?
What user experience happens?
例如 Uber：
Driver location
→ slight staleness acceptable
Ride assignment
→ stronger consistency
AI SaaS：
Usage dashboard
→ slight delay acceptable
Authorization
→ stale permission may be dangerous
前面已詳細學過：
Redundancy
Health Check
Failover
Timeout
Retry
Backoff
Jitter
Circuit Breaker
Bulkhead
Graceful Degradation
現在重點是：
找出 Critical Dependencies。
Critical Dependency（關鍵依賴）
Failure 後可能讓核心 User Flow 無法完成的 Dependency。
例如：
Authentication Service
Message Storage
Payment Database
Optional Dependency（非核心依賴）
Failure 時，核心 Product 仍可以繼續。
例如：
Recommendation
Analytics
Typing Indicator
如果 Recommendation Service 掛掉：
Video Playback
可能仍然能運作。
這就是 Graceful Degradation 的實際思考方式。
前面已學：
Authentication
Authorization
Encryption
TLS
RBAC
Secrets
Audit
Prompt Injection
Tenant Isolation
至少問：
Who can access this?
How is identity verified?
How is data protected?
What sensitive data exists?
新名詞：
Principle = 原則
Least = 最少的
Privilege = 權限 / 特權
完整：
Principle of Least Privilege = 最小權限原則
意思：
User、Service、Process 只取得完成工作所必要的最小 Permissions。
例如：
Calendar Agent
如果只需要：
Read Calendar
就不要給：
Delete All Events
目的之一就是降低：
Blast Radius
前面已學：
Metrics
Logs
Traces
SLI
SLO
SLA
Alerts
現在問：
How do I know the system is healthy?
How do I debug a failure?
Business Metric（商業 / 業務指標）
描述 Product 或 Business 是否正常運作的 Metric，而不只是
Infrastructure Health。
例如：
Notification delivery rate
Successful agent tasks
Cost per tenant
Payment success rate
Technical Metric（技術指標）
例如：
CPU
Memory
RPS
Error Rate
P99 Latency
Queue Depth
好的 Observability 通常需要：
Technical Metrics
+
Business Metrics
Distributed System 的重要觀念：
Failure 一定會發生。
快速掃描：
Application Server Crash?
Database Crash?
Cache Crash?
Queue Unavailable?
Worker Crash?
Network Timeout?
Duplicate Request?
Out-of-Order Event?
Provider Failure?
Region Failure?
Traffic Spike?
AI 題目再加：
LLM Provider unavailable?
Model rate limited?
Vector DB slow?
Tool call fails?
Agent loops forever?
Prompt injection?
Token cost explodes?
不要說：
Redis is better.
NoSQL is better.
Microservices are better.
Sharding is better.
要問：
Better for which requirement?
What do we give up?
最好使用：
Requirement
↓
Options
↓
Trade-offs
↓
Decision
↓
Reason
逐字：
A = Architecture = 架構
D = Decision = 決策
R = Record = 紀錄
完整：
Architecture Decision Record
= 架構決策紀錄
用途：
記錄某個 Architecture Decision、原因與 Trade-offs。
例如：
Decision:
Use PostgreSQL for orders.
Reason:
Need transactions and relational queries.
Trade-off:
Horizontal write scaling can become more complex.
面試不一定要真的寫 ADR。
但它的 Mental Model 很好用：
Choice + Why + Cost
常見 Follow-up：
What if traffic grows 10x?
不要只回答：
Add more servers.
重新找：
Application CPU?
DB Reads?
DB Writes?
Cache Capacity?
Network?
Storage?
Queue Backlog?
Worker Throughput?
External API Limit?
GPU Capacity?
原本：
Client
↓
Spring Boot
↓
PostgreSQL
成長：
Clients
↓
Load Balancer
↓
Spring Boot × N
↓
Redis
↓
PostgreSQL Primary
├── Read Replica
└── Read Replica
Background Work：
Application
↓
Queue
↓
Workers
再根據真正 Bottleneck 決定：
Partition?
Sharding?
Separate Service?
AI 題目要額外問：
Which Model?
Context Window?
RAG needed?
Latency target?
Streaming?
Token Cost?
Model Rate Limits?
Evaluation?
Hallucination?
Safety?
Agent Tools?
Human Approval?
這些 Day 25～29 已詳細介紹，不重複定義。
User Request
↓
Authentication
↓
Rate Limit / Quota
↓
Prompt / Context
↓
Optional Retrieval
↓
Model / Agent
↓
Optional Tools
↓
Guardrails
↓
Response
↓
Usage / Cost Tracking
↓
Evaluation / Observability
Production AI Application 通常不只是：
User → LLM → Answer
最後 1～2 分鐘可以 Summary：
Requirements
Architecture
Main Bottleneck
Scaling Strategy
Consistency Choice
Reliability Strategy
Main Trade-off
例如 Chat：
We designed a horizontally scalable chat service using persistent
WebSocket connections for real-time delivery, durable message storage
for history, and asynchronous processing for non-critical work. We
partition messages by conversation for practical per-conversation
ordering and use retries plus idempotency for delivery reliability.
拿到任何題目，可以先寫：
1. Requirements
2. Scale
3. Entities
4. API
5. Data Model
6. HLD
7. Critical Flow
8. Bottlenecks
9. Scaling
10. Consistency
11. Reliability
12. Security
13. Observability
14. Failure Scenarios
15. Trade-offs
16. 10x Scale
17. Summary
AI 題目再加：
18. Model / RAG / Agent
19. Cost
20. Evaluation / Safety
Requirements
→ Email / SMS / Push?
→ Scheduled?
→ Priority?
Scale
→ Notifications/day?
→ Peak?
Entities
→ Notification
→ User
→ Template
API
→ Create notification
HLD
→ API → Queue → Workers → Providers
Reliability
→ Retry
→ DLQ
→ Idempotency
Scaling
→ More workers
Trade-off
→ At-least-once may create duplicates
Requirements
→ Shorten + Redirect
Scale
→ Read-heavy
Entity
→ URL Mapping
API
→ POST /urls
→ GET /{code}
Data
→ short_code → long_url
HLD
→ Client → LB → App → Cache → DB
Bottleneck
→ Redirect reads
Scaling
→ Cache
Reliability
→ Replication
Requirements
→ Messaging
→ History
→ Online delivery
Scale
→ Millions of connections
Entities
→ User
→ Conversation
→ Message
Communication
→ WebSocket
Storage
→ Durable Message Store
Ordering
→ Per Conversation
Offline
→ Persist + Push Notification
Reliability
→ ACK + Retry + Dedup
Scaling
→ Connection Servers + Routing + Partitioning
Requirements
→ Upload
→ Process
→ Playback
Scale
→ Huge Binary Files
→ Huge Bandwidth
Storage
→ Object Storage
Processing
→ Queue + Transcoding Workers
Playback
→ Segments + Manifest + CDN
Reliability
→ Resumable Upload + Retry
Scaling
→ CDN absorbs playback traffic
Requirements
→ Driver Location
→ Matching
→ Trip Tracking
Scale
→ Frequent location updates
Data
→ Geospatial Data
Search
→ Spatial Index
Matching
→ Nearby Candidates + Ranking
Consistency
→ Ride Assignment stronger
→ Location can tolerate slight staleness
Real-Time
→ WebSocket
Scaling
→ Geographic Partitioning
Requirements
→ Answer using private documents
Ingestion
→ Parse
→ Chunk
→ Embed
→ Index
Query
→ Embed
→ Retrieve
→ Rerank
→ Prompt
→ LLM
Security
→ Access-Control Filtering
Quality
→ Retrieval Evaluation
Freshness
→ Incremental Updates
Requirements
→ Multi-step Task Execution
Core
→ LLM + Tools + State
Execution
→ Agent Loop
Long-running Work
→ Task Queue + Workers
Reliability
→ Checkpoint + Durable Execution
Security
→ Tool Gateway + Least Privilege
Dangerous Actions
→ Human Approval
Cost
→ Max Steps + Token / Tool Budgets
Requirements
→ Multiple Enterprise Customers
Tenant
→ Organization / Workspace
Identity
→ SSO / SCIM
Authorization
→ RBAC
Product Access
→ Entitlements
Data
→ Tenant Isolation
AI
→ RAG + Agent + Model Gateway
Billing
→ Usage Metering
Security
→ KMS / BYOK
Scale
→ Quotas + Fair Scheduling + Worker Scaling
Enterprise
→ Audit + Data Residency + SLA
不要想：
Do I have Redis?
Do I have Kafka?
Do I have Kubernetes?
Do I have NoSQL?
應該想：
Do I have repeated expensive reads?
→ Maybe Cache
Do I have slow asynchronous work?
→ Maybe Queue
Do I have read scaling problems?
→ Maybe Replica
Does one DB exceed capacity?
→ Maybe Partition / Sharding
Problem Possible Component
Too many app requests Load Balancer + Horizontal Scaling
Repeated expensive reads Cache
Global static content CDN
Slow background work Message Queue + Workers
Too many DB reads Cache / Read Replica
DB exceeds capacity Partition / Sharding
API abuse Rate Limiter
Service failure Redundancy / Failover
Production debugging Metrics / Logs / Traces
Real-time bidirectional communication WebSocket
Large binary storage Object Storage
Semantic document search Embedding + Vector Search
Private/current LLM knowledge RAG
Multi-step AI actions Agent
Dangerous AI action Human Approval / Policy
Multiple SaaS customers Multi-Tenant Isolation
Enterprise login SSO
Enterprise user lifecycle SCIM
Usage-based pricing Metering + Billing
右邊只是：
Possible Solution
不是看到 Problem 就一定必須用。
每畫一個 Box，都問：
What problem does this box solve?
如果回答不出來：
可能不需要這個 Box。
再追問：
What happens if it fails?
How does it scale?
What trade-off does it introduce?
Overengineering（過度設計）
使用遠超過目前 Requirements 所需的 Complexity。
例如：
100 daily users
卻直接：
20 Microservices
64 DB Shards
Multi-Region Active-Active
不一定是好 Design。
Underengineering（設計不足）
Design 明顯無法滿足已知 Requirements。
例如：
100M users
卻只有：
One Server
One Local DB
No Backup
目標不是：
Most complicated architecture
而是：
Enough complexity
to satisfy requirements
without unnecessary complexity
逐字：
Y = You = 你
A = Aren't = 不會 / 不需要
G = Gonna = Going to 的口語形式
N = Need = 需要
I = It = 它
核心意思：
現在沒有 Requirement 的東西，不要只因為「未來可能需要」就全部先做。
例如：
10K users
Single Region
沒有 Requirement：
Global Active-Active
就不一定要先做。
逐字：
K = Keep = 保持
I = It = 它
S = Simple = 簡單
S = Stupid = 原句中的強調用語
工程上理解：
能用簡單方法正確解決問題，就不要不必要地增加 Complexity。
例如 PostgreSQL 已足夠時，不一定要：
PostgreSQL
+ MongoDB
+ Cassandra
+ Elasticsearch
全部一起使用。
逐字：
D = Don't = 不要
R = Repeat = 重複
Y = Yourself = 自己
完整：
Don't Repeat Yourself
= 不要重複自己
意思：
避免同一份 Knowledge / Logic 被不必要地複製很多次。
但 DRY 也不能過度。
兩段 Code 現在看起來相似，不代表一定屬於同一個 Business Concept。
Microservices（微服務）
Micro = 微小的
Services = 服務
把 Application 拆成多個可以相對獨立開發、部署與運作的 Services。
例如：
User Service
Order Service
Payment Service
Notification Service
Monolith（單體式應用）
多個 Application Capabilities 主要在同一個 Application Deployment Unit
中。
例如：
One Spring Boot Application
├── User
├── Order
├── Payment
└── Notification
非常重要：
Monolith ≠ Bad
Microservices ≠ Good
拆成 Microservices 後會增加：
Network Calls
Distributed Tracing
Service Discovery
Deployment Complexity
Distributed Transactions
Version Compatibility
More Failure Modes
所以小團隊 / 新 Product 使用 Monolith 可能反而更合理。
Modular = 模組化的
Modular Monolith = 模組化單體
Application 仍是一個主要 Deployment Unit，但內部維持清楚 Module
Boundaries。
例如：
Application
├── User Module
├── Order Module
├── Payment Module
└── Notification Module
它可以是 Microservices 之前很合理的起點。
Service Boundary（服務邊界）
決定某個 Responsibility、Data、Business Capability 屬於哪個 Service。
不一定：
One Database Table = One Service
更常考慮：
Business Capability
Ownership
Scaling Needs
Change Frequency
Failure Isolation
Conway's Law（康威定律）
簡化理解：
Organization 的 Communication Structure 往往會反映在它設計出的 System
Structure 上。
例如：
Team A
Team B
Team C
分別負責不同 Business Areas，
System 也可能逐漸形成：
Service A
Service B
Service C
Architecture 不只受到 Technology 影響，也受到：
Team Structure
Ownership
Communication
Operations
影響。
Operational = 維運相關的
Operational Complexity = 維運複雜度
System 在 Deployment、Monitoring、Incident
Handling、Backup、Scaling、Upgrade 等方面的複雜程度。
例如：
1 PostgreSQL
和：
50 DB Shards
Operational Complexity 完全不同。
Operability（可維運性）
System 是否容易被 Engineering / Operations Team
部署、監控、維修、升級與處理 Incident。
好的 Architecture 不只：
Works on diagram
還要：
Can be operated in production
Agnostic = 不綁定特定選擇的
Technology-Agnostic = 技術中立 / 不綁特定技術
例如先說：
Distributed Cache
再補：
Redis could be one implementation.
而不是：
Redis because everyone uses Redis.
Deep Dive（深入探討）
HLD 完成後，選一兩個重要 Area 深入分析。
例如：
Chat
→ Message Ordering
Uber
→ Driver Matching
YouTube
→ Video Processing
RAG
→ Retrieval Quality
Breadth（廣度）
涵蓋多少不同 Areas。
Depth（深度）
某個 Area 分析多深入。
System Design Interview 要平衡：
Breadth + Depth
不能只有：
Broad boxes
也不能：
40 minutes on one SQL query
假設 45 分鐘，可以粗略：
5 min
→ Requirements + Scope
5 min
→ Estimation + API + Data Model
10 min
→ HLD
15 min
→ Deep Dive + Bottlenecks + Scaling
5 min
→ Reliability + Security + Observability
5 min
→ Trade-offs + Summary
不是固定規則。
Interviewer 可能會主動帶方向。
畫 Architecture 時同步說：
I'm adding a cache because this is a read-heavy path.
I'm keeping application servers stateless so they can scale horizontally.
I'm using asynchronous workers because this task doesn't need to block the user request.
Interviewer 才看得到你的 Reasoning。
Red Flag（警訊）
常見 System Design Red Flags：
Immediately chooses technologies
No requirements questions
No scale assumptions
No failure discussion
No trade-offs
Uses sharding everywhere
Uses microservices everywhere
Ignores security
Cannot explain why a component exists
Strong Signal（強烈正面訊號）
例如：
Clarifies requirements
Makes assumptions explicit
Connects choices to requirements
Explains trade-offs
Recognizes failure modes
Changes design when assumptions change
Starts simple
如果面試官問：
內部系統 User 從 2,000 成長到 20,000，你怎麼 Scale？
可以：
1. Measure current bottleneck
2. Check CPU / Memory / Latency / DB
3. Make app stateless
4. Add Load Balancer
5. Horizontally scale app servers
6. Optimize DB queries
7. Add indexes
8. Cache hot reads
9. Add read replicas if needed
10. Move slow background work to Queue
11. Partition / Shard only if necessary
12. Add Observability
I would first measure where the current bottleneck is instead of
assuming every layer needs to scale. If the application tier is
saturated, I would make it stateless and horizontally scale it behind
a load balancer. If the database is the bottleneck, I would first
review slow queries and indexes, then consider caching hot reads or
adding read replicas. For slow non-critical tasks, I would move them
to asynchronous workers. I would only introduce sharding when simpler
approaches can no longer meet the required capacity because sharding
adds significant operational complexity.
核心：
Requirement
→ Bottleneck
→ Incremental Solution
→ Trade-off
題目：
Design an internal AI assistant for engineers.
先問：
What documents?
How fresh?
How many users?
Private data?
Can it call tools?
Read-only or write actions?
Latency target?
Need citations?
Architecture：
Employee
↓
Authentication
↓
Authorization
↓
AI API
↓
RAG
↓
Access-Controlled Retrieval
↓
LLM
↓
Citation
如果是 Agent：
Tool Gateway
↓
Least Privilege
↓
Approval for dangerous actions
問：
Can model output directly trigger a dangerous action?
如果：
LLM
↓
Delete Production Database
就非常危險。
需要：
Policy
Authorization
Tool Restrictions
Human Approval
Audit
問：
What controls the maximum cost of one request/task?
例如：
Max Input Tokens
Max Output Tokens
Max Agent Steps
Max Tool Calls
Timeout
Tenant Quota
Budget
問：
How do we know the AI system is actually good?
不能只看：
HTTP 200
還要：
Evaluation
Retrieval Quality
Answer Quality
Task Success Rate
Hallucination Rate
User Feedback
REQUIREMENTS
□ Functional Requirements
□ Non-Functional Requirements
□ Scope
□ Assumptions
□ Constraints
□ Priorities
SCALE
□ Users
□ RPS / QPS
□ Peak Traffic
□ Storage
□ Bandwidth
□ Read / Write Ratio
DATA
□ Core Entities
□ Relationships
□ Access Patterns
□ SQL / NoSQL
□ Index
□ Replication
□ Partition / Sharding
API
□ Core APIs
□ Request / Response
□ Idempotency
□ Pagination if needed
ARCHITECTURE
□ Client
□ Load Balancer / API Gateway
□ Application Services
□ Cache
□ Database
□ Queue / Workers
□ Object Storage
□ CDN if needed
CONSISTENCY
□ Strong or Eventual?
□ Which data?
□ Replication Lag?
□ Ordering?
□ Duplicate Handling?
RELIABILITY
□ SPOF?
□ Redundancy
□ Health Check
□ Failover
□ Timeout
□ Retry
□ Backoff
□ Circuit Breaker
□ Graceful Degradation
SECURITY
□ Authentication
□ Authorization
□ Least Privilege
□ Encryption
□ Secrets
□ Audit
□ Tenant Isolation
OBSERVABILITY
□ Metrics
□ Logs
□ Traces
□ Alerts
□ Business Metrics
FAILURES
□ Server Crash
□ DB Failure
□ Cache Failure
□ Queue Backlog
□ Worker Crash
□ Network Failure
□ Provider Failure
□ Traffic Spike
TRADE-OFFS
□ Why this DB?
□ Why this Cache?
□ Why this Queue?
□ Why this Consistency Model?
□ What complexity did we add?
SCALE 10X
□ New Bottleneck?
□ App Scaling?
□ DB Scaling?
□ Storage?
□ Network?
□ Async Workers?
AI IF APPLICABLE
□ Model
□ Context Window
□ RAG
□ Retrieval Quality
□ Agent
□ Tools
□ Guardrails
□ Human Approval
□ Cost
□ Evaluation
□ Hallucination
□ Prompt Injection
□ Usage / Quota
R = Representational = 表述性的 / 表示形式的
S = State = 狀態
T = Transfer = 傳輸
REST
= Representational State Transfer
= 表述性狀態傳遞
C = Create = 建立
R = Read = 讀取
U = Update = 更新
D = Delete = 刪除
CRUD
= Create, Read, Update, Delete
= 建立、讀取、更新、刪除
H = High = 高階
L = Level = 層級
D = Design = 設計
HLD
= High-Level Design
= 高階設計
L = Low = 低階 / 細節層級
L = Level = 層級
D = Design = 設計
LLD
= Low-Level Design
= 低階設計 / 詳細設計
A = Architecture = 架構
D = Decision = 決策
R = Record = 紀錄
ADR
= Architecture Decision Record
= 架構決策紀錄
Y = You = 你
A = Aren't = 不會 / 不需要
G = Gonna = Going to 的口語形式
N = Need = 需要
I = It = 它
YAGNI
= You Aren't Gonna Need It
K = Keep = 保持
I = It = 它
S = Simple = 簡單
S = Stupid = 原句中的強調用語
KISS
= Keep It Simple, Stupid
D = Don't = 不要
R = Repeat = 重複
Y = Yourself = 自己
DRY
= Don't Repeat Yourself
= 不要重複自己
DNS
HTTP
HTTPS
TCP
UDP
TLS
API
SQL
NoSQL
ACID
CAP
CDN
TTL
ACK
DLQ
RPS
QPS
DAU
SPOF
SLI
SLO
SLA
WebSocket
WSS
E2EE
APNs
FCM
GPS
ETA
LLM
GPT
NLP
TTFT
RAG
GPU
CPU
VRAM
TPM
RPM
SSO
SAML
SCIM
KMS
DEK
KEK
BYOK
SIEM
HPA
RBAC
SaaS
B2B
B2C
以及：
Load Balancer
Cache
Replication
Sharding
Message Queue
Rate Limiter
Consistency
Reliability
Observability
Authentication
Authorization
Embedding
Vector Database
AI Agent
Tool Gateway
Guardrail
Multi-Tenant
都直接沿用前面 Days 的知識。
1. Requirement before Technology
2. Scale changes Architecture
3. Every Component must solve a Problem
4. Database choice depends on Access Pattern and Requirements
5. Cache improves speed but creates Consistency Complexity
6. Queue removes work from Critical Path but introduces Async Complexity
7. Distributed Systems must expect Failure
8. There is no free Consistency / Availability / Scalability choice
9. Security and Observability are part of Architecture
10. System Design is about Trade-offs, not perfect answers
一開始可能只想：
How do I implement this endpoint?
System Design 會多想：
What happens with 10M users?
What if server crashes?
What if DB is slow?
What if the same request arrives twice?
What if network fails?
What if user is offline?
What if one tenant accesses another tenant's data?
What if traffic grows 10x?
What if AI Agent performs a dangerous action?
What if AI cost grows 100x?
這就是思考層級的改變。
題目：
Design a system where engineers upload internal documents and ask an
AI questions about them.
用 Framework：
1. Requirements
→ Upload documents
→ Ask questions
→ Private data
→ Citation required
2. Scale
→ 10K employees
→ 1M documents
→ 100K questions/day
3. Entities
→ User
→ Document
→ Chunk
→ Knowledge Base
→ Query
4. API
→ Upload document
→ Ask question
5. Data
→ Metadata DB
→ Object Storage
→ Vector Index
6. HLD
Employee
↓
API Gateway
↓
Authentication
↓
RAG Service
↓
Retriever
↓
Vector DB
↓
LLM
7. Ingestion
Document
↓
Parser
↓
Chunk
↓
Embedding
↓
Vector Index
8. Security
→ User Permissions
→ Document ACL
→ Tenant Filter
→ Encryption
9. Reliability
→ Ingestion Queue
→ Retry
→ DLQ
10. Quality
→ Retrieval Evaluation
→ Citation
→ Answer Evaluation
11. Cost
→ Token Limits
→ Model Routing
→ Cache
12. Observability
→ Latency
→ Retrieval Quality
→ Token Cost
→ Failure Rate
13. Trade-off
→ Better Model may improve Quality
→ but increase Latency and Cost
14. Scale 10x
→ Stateless Service Scaling
→ Partition Ingestion
→ Scale Vector Search
→ Worker Autoscaling
→ Quota
你不需要背某一家公司的 Architecture，也可以一步一步設計。
這就是 Framework 的價值。
Day 1
System Design Mindset
Day 2
Request Journey
Day 3
Vertical vs Horizontal Scaling
Day 4
Load Balancer
Day 5
SQL vs NoSQL
Day 6
Database Index
Day 7
Cache / Redis
Day 8
Database Replication
Day 9
Database Sharding
Day 10
CDN
Day 11
Message Queue
Day 12
Rate Limiter
Day 13
Consistency
Day 14
CAP Theorem
Day 15
Reliability
Day 16
Observability
Day 17
Security
Day 18
System Design Interview Process
Day 19
Back-of-the-Envelope Estimation
Day 20
Design URL Shortener
Day 21
Design Notification System
Day 22
Design Chat System
Day 23
Design YouTube
Day 24
Design Uber
Day 25
AI System Design Introduction
Day 26
Design RAG System
Day 27
AI Agent Architecture
Day 28
Production AI Agent System
Day 29
Design AI SaaS
Day 30
Final System Design Framework
表面上學了很多 Technology：
Redis
Load Balancer
Queue
CDN
Database
WebSocket
Vector DB
LLM
Agent
但真正核心一直都是：
Problem
↓
Requirement
↓
Constraint
↓
Simplest Design
↓
Bottleneck
↓
Scale
↓
Failure
↓
Trade-off
Mental Model（心智模型 / 思考模型）
幫助我們理解與推理複雜問題的一套思考方式。
最後可以記：
Who uses it?
↓
What do they need?
↓
How big is it?
↓
What data exists?
↓
What is the simplest design?
↓
Where will it break?
↓
How do we scale that bottleneck?
↓
What happens when something fails?
↓
What consistency do we need?
↓
How do we secure it?
↓
How do we observe it?
↓
What trade-off did we make?
↓
What changes at 10x scale?
30 天結束後，不需要期待自己看到任何 System Design
題目都立刻知道「標準答案」。
真正應該得到的是：
看到陌生問題時，你知道第一個問題該問什麼；知道 Architecture
應該從簡單開始；知道怎麼找 Bottleneck；也知道每增加一個
Component，都必須能說明它解決了什麼問題，以及帶來什麼 Trade-off。
如果面試官問：
Design a system you've never seen before.
你不需要先看過那張 Architecture Diagram。
從：
Requirements
開始，一步一步走到：
Scale
Data
API
Architecture
Bottleneck
Reliability
Security
Observability
Trade-offs
AI 題目再加入：
RAG
Agent
Safety
Evaluation
Cost
這就是這 30 天真正想建立的能力。
System Design 不是背 Architecture，而是學會在 Constraints 下做合理的
Engineering Decisions。
把整個系列濃縮成一句：
Requirement
→ Simplest Working Design
→ Find Bottleneck
→ Scale
→ Handle Failure
→ Explain Trade-offs
30 Days of System Design --- 完。
iThome鐵人賽
看影片追技術