Day 23 我們設計了大型 Video Platform。今天來看另一個經典 System Design
題目：
Design Uber（設計叫車系統）
今天仍然遵守同一個規則：
每一個新名詞都先解釋「完整英文 → 中文意思 → 是什麼 → 為什麼需要 →
簡單例子 → System Design 用法」。如果是縮寫，也把每一個字拆開。
Requirements（需求）：System 必須提供或滿足的功能與品質。
不要一看到 Design Uber 就先回答
Redis、Kafka、WebSocket。先確認我們到底要設計什麼。
Functional Requirements（功能性需求）：System 必須提供哪些功能。
1. Driver 持續更新 Location
2. Passenger 輸入 Pickup Location 與 Destination
3. Passenger Request Ride
4. System 找附近 Available Drivers
5. Passenger 與 Driver Matching
6. Driver / Passenger 可以看到 Trip Location Update
7. System 管理 Trip Status
8. Trip 結束後保存 Trip Record
今天先不深入 Payment、Rating、Promotion、Fraud Detection 與完整 Surge
Pricing。
Non-Functional Requirements（非功能性需求）：System 應具備什麼品質。
Low Latency
High Availability
Scalability
Fresh Location Data
Reliable Matching
Reasonable Consistency
GPS = Global Positioning System
逐字：
Global → 全球的
Positioning → 定位
System → 系統
中文：
全球定位系統
GPS 使用衛星訊號協助 Device
計算位置。手機取得位置後，可以把類似下面的資料傳給 Backend：
Latitude
Longitude
實際手機定位也可能結合 Wi-Fi、Cellular Network 等資訊；System Design
面試通常先簡化成「Client 取得 Location，再回報 Backend」。
Latitude（緯度）：
表示一個位置相對於赤道往北或往南的位置。
範圍大致：
-90° ～ +90°
Longitude（經度）：
表示一個位置相對於本初子午線往東或往西的位置。
範圍大致：
-180° ～ +180°
一個 Geographic Location 常表示成：
(latitude, longitude)
Coordinate（座標）：
用一組數值表示某個位置。
一般二維平面：
(x, y)
地理位置：
(latitude, longitude)
Geolocation
Geo → 地球 / 地理
Location → 位置
中文：
地理定位
意思：
取得或表示 Device / User 的地理位置。
Geospatial Data
Geo → 地理
Spatial → 空間的
Data → 資料
中文：
地理空間資料
意思：
和真實世界位置、距離、區域有關的 Data。
例如：
Driver Location
Pickup Location
Restaurant Location
Delivery Address
Driver 一直移動：
10:00:00 → A
10:00:03 → B
10:00:06 → C
所以 Driver App 要持續傳：
Location Update（位置更新）
把 Driver 最新位置傳給 Backend。
Driver App
↓
latitude + longitude + timestamp
↓
Location Service
Service（服務） 在 System Design 中：
負責某一類 Responsibility 的 Backend Component。
Location Service（位置服務）：
專門接收、更新與提供 Driver Location 的 Component。
Driver App
↓
Location Service
↓
Location Store
Frequency（頻率）：
一件事情在一定時間內發生多少次。
例如 Location Update：
Every 1 second
Every 3 seconds
Every 10 seconds
更新越頻繁：
Location fresher
但也會增加：
Network Traffic
Backend Load
Battery Usage
Processing Cost
所以是 Trade-off。
Freshness（資料新鮮度）：
Data 距離最新真實狀態有多接近。
如果 Driver 已經移動 500 公尺，但 Server 還保留 20 秒前的位置，Freshness
就不好。
Stale Data（過期資料 / 舊資料）
Stale → 過時、不新鮮的
意思：
System 看到的 Data 已不是最新狀態。
Driver Location 很重視 Freshness，但不代表每一筆 Location 都需要 Strong
Consistency。
Ride Request（叫車請求）：
Passenger 告訴 System「我想從這裡搭車到那裡」。
可能包含：
passenger_id
pickup_location
destination
requested_at
Pickup Location（上車地點）：
Pickup → 接人 / 接送
Location → 地點
就是 Driver 要去接 Passenger 的地方。
Destination（目的地）：
Passenger 最後想去的位置。
Available（可用的 / 可以接單的）
Available Driver（可接單司機）：
目前可以接受新 Ride Request 的 Driver。
例如：
Driver A → AVAILABLE
Driver B → ON_TRIP
Driver C → OFFLINE
只有 A 適合進入 Matching Candidates。
Matching（配對）：
根據條件，把 Passenger 的 Ride Request 和適合的 Driver 配對。
可能考慮：
Distance
ETA
Driver Availability
Vehicle Type
Traffic
今天先簡化：
Find nearby available drivers
↓
Rank candidates
↓
Offer ride
Matching Service（配對服務）：
負責根據 Ride Request 找出並選擇適合 Driver 的 Backend Component。
Radius（半徑）：
從中心點向外的一段距離。
例如：
Find available drivers within 3 km
Passenger Location 就是圓心，3 km 是 Radius。
Distance（距離）：
兩個位置之間相隔多遠。
但要區分：
Straight-Line Distance
vs
Driving Distance
隔著一條河時，直線可能只有 500 m，但實際開車可能要 5 km。
Straight-Line Distance（直線距離）：
兩點直接連線的距離。
它適合快速篩選 Candidates，但不一定代表 Driver 真正要開的距離。
Route（路線）：
從起點到終點實際可以行駛的道路路徑。
Routing（路線規劃）：
根據道路 Network 找出從 A 到 B 的可行或適合路線。
注意：
這裡是 Road Routing，不是 Internet Packet Routing。
ETA = Estimated Time of Arrival
逐字：
Estimated → 估計的
Time → 時間
Arrival → 抵達
中文：
預估抵達時間
例如：
Driver is 2 km away
ETA = 5 minutes
Passenger 真正關心的通常不是「直線幾公里」，而是：
司機多久會到？
Geospatial Search（地理空間搜尋）：
根據地理位置、距離或區域尋找 Data。
例如：
Find all available drivers
within 3 km of passenger
假設：
1,000,000 online drivers
Passenger 在 Boston 叫車。
最笨的方法：
Read every driver
↓
Calculate every distance
↓
Find nearby drivers
大部分 Driver 根本不在 Boston。
因此需要更有效率的方法縮小搜尋範圍。
Spatial Index
Spatial → 空間的
Index → 索引
中文：
空間索引
意思：
專門幫助 System 快速搜尋地理 / 空間位置的 Index。
普通 Index 可能幫助：
Find user by email
Spatial Index 幫助：
Find drivers near this coordinate
核心：
不要每次都掃描全世界的 Driver。
Geohash
Geo → 地理
Hash → 這裡先理解成一種區域編碼方式
中文可理解為：
地理位置編碼
核心概念：
把地球切成很多區域，再用 String 表示某個區域。
例如概念上：
latitude + longitude
↓
geographic cell
↓
"drt..."
System 可以先找 Passenger 所在區域附近的 Drivers，而不是掃描所有
Drivers。
Cell（格子 / 區塊）：
地理空間切分後的一小塊 Area。
想像：
+-----+-----+-----+
| A1 | A2 | A3 |
+-----+-----+-----+
| B1 | B2 | B3 |
+-----+-----+-----+
| C1 | C2 | C3 |
+-----+-----+-----+
Passenger 在 B2，可以先找 B2 附近的 Drivers。
Neighboring Cell（相鄰格子）：
和目前 Cell 接近的其他 Cells。
如果 Passenger 在 B2 邊界，最近 Driver 可能其實在 B3。
因此不能只查一個 Cell。
Precision（精細程度 / 精度）：
Location Representation 有多細。
概念上：
Larger Cell → lower precision
Smaller Cell → higher precision
Geohash 類型的編碼通常可以用不同長度表示不同精細程度。
Geohash 可以：
快速找到 Candidate Areas
但：
Same Cell
不代表每個 Driver 距離 Passenger 一樣近。
因此常見流程：
Spatial Index / Geohash
↓
Find candidate drivers
↓
Calculate accurate distance / ETA
↓
Rank candidates
Candidate（候選者）：
還沒正式被選中，但已符合初步條件的對象。
例如：
Candidate Drivers:
A
B
C
D
Ranking（排序 / 排名）：
根據 Criteria 決定 Candidates 的優先順序。
例如：
Driver A → ETA 2 min
Driver B → ETA 4 min
Driver C → ETA 7 min
Criteria（標準 / 條件）：
用來評估和比較 Candidates 的規則。
例如：
ETA
Distance
Availability
Vehicle Type
Passenger Ride Request
↓
Matching Service
↓
Passenger Location
↓
Geospatial Search
↓
Nearby Available Drivers
↓
Candidate Drivers
↓
Distance / ETA
↓
Ranking
↓
Reserve Driver
↓
Ride Offer
Ride Offer（接單邀請）：
System 把 Ride Request 提供給 Driver，詢問是否接受。
Pickup: 2 min away
Destination: Airport
Accept?
Decline?
現在有一個問題：
Passenger A → sees Driver X AVAILABLE
Passenger B → sees Driver X AVAILABLE
兩邊都想 Assign Driver X。
這叫：
Race Condition（競爭條件）：
多個 Operations 同時操作 Shared Data，而結果可能因執行順序產生錯誤。
Shared Data（共享資料）：
多個 Requests / Processes 都可能讀寫的同一份 Data。
例如：
Driver X status = AVAILABLE
Atomic Operation（原子操作）：
一個 Operation 對其他 Concurrent Operations
看起來像不可被切成一半的單一動作。
我們希望：
IF Driver X is AVAILABLE
THEN set Driver X = RESERVED
這個「檢查 + 修改」不要被兩個 Matching Requests 同時成功。
Compare-And-Set
Compare → 比較
Set → 設定
意思：
只有目前值仍等於預期值時，才修改成新值。
概念：
Expected = AVAILABLE
New = RESERVED
如果另一個 Request 已先改成 RESERVED，第二個就失敗。
Reservation（保留 / 暫時預留）：
暫時把 Resource 留給某個 Operation，避免其他人同時取得。
AVAILABLE
↓
RESERVED for Passenger A
Driver 拒絕或 Timeout：
RESERVED
↓
AVAILABLE
Timeout（逾時）：
Operation 等待超過允許時間後，不再無限等待。
例如 Driver 有 15 秒接受 Ride。
沒有回覆：
Offer Timeout
↓
Release Reservation
↓
Try next Driver
Trip（行程）：
從 Passenger 叫車、Driver 接單、前往 Pickup、載客、抵達 Destination
到完成的一整個 Business Process。
Trip 會經歷很多 States。
State（狀態）：
Entity 在某個時間點所處的情況。
例如：
REQUESTED
MATCHING
DRIVER_ASSIGNED
DRIVER_ARRIVING
IN_PROGRESS
COMPLETED
CANCELLED
State Transition（狀態轉換）：
Transition → 轉換
意思：
Entity 從一個 State 變成另一個 State。
例如：
REQUESTED
↓
MATCHING
↓
DRIVER_ASSIGNED
State Machine（狀態機）：
用明確 States 與允許的 State Transitions 管理 Process。
REQUESTED
↓
MATCHING
↓
DRIVER_ASSIGNED
↓
DRIVER_ARRIVING
↓
IN_PROGRESS
↓
COMPLETED
也可能：
REQUESTED → CANCELLED
MATCHING → CANCELLED
DRIVER_ASSIGNED → CANCELLED
State Machine 可以避免：
COMPLETED → MATCHING
這種不合理 Transition。
Real-Time（即時）：
Event 發生後，System 能在很短時間內把結果反映給相關 User。
例如：
Driver moves
↓
Passenger Map updates shortly after
Real-Time 不一定等於 0 ms，而是：
足夠快到符合 Product Requirement。
Polling（輪詢）：
Client 每隔一段時間主動問 Server：「有新資料嗎？」
例如：
Every 3 seconds:
Passenger App
→ GET latest driver location
→ Server
優點：
Simple
缺點：
很多 Requests 可能沒有任何新 Data
WebSocket：
一種讓 Client 與 Server 建立長時間、雙向 Communication Connection 的
Protocol。
一般 HTTP：
Client asks
↓
Server responds
WebSocket：
Client ↔ Server
Connection 可以維持，Server 有新 Location 時可以主動 Push。
Protocol（協定）：
Communication 雙方共同遵守的規則。
例如：
HTTP
TCP
WebSocket
Bidirectional（雙向的）
Bi → 兩個
Directional → 方向的
意思：
Client → Server
Server → Client
兩個方向都可以傳 Data。
Push（推送）：
Server 有新 Data 時主動傳給 Client，而不是等 Client 下一次 Poll。
Driver Location Updated
↓
Server
↓
Push
↓
Passenger
Polling WebSocket
Client 定期主動問 建立長連線等待
Server Push 不是真正主動 Push 可以
Implementation 較簡單 較複雜
Frequent Real-Time Update Traffic 可能很高 通常更適合
不是 WebSocket 永遠比較好，而是看 Requirement。
Connection（連線）：
兩個 Network Endpoints 之間的 Communication Relationship。
如果有：
1M active users
而每個 User 都維持 WebSocket：
1M long-lived connections
Connection Management 本身就是 Scaling Problem。
Connection Server（連線伺服器）：
專門管理大量 Client Long-Lived Connections 的 Server。
Passenger Apps
↓
Connection Servers
↓
Real-Time Events
Connection Mapping（連線對應關係）：
記錄某個 User 目前連在哪一台 Connection Server。
例如：
passenger_123
→ connection_server_7
這樣 Backend 才知道 Event 應該 Push 到哪裡。
Event（事件）：
表示「某件事情已經發生」的 Message。
例如：
DRIVER_LOCATION_UPDATED
RIDE_REQUESTED
DRIVER_ASSIGNED
TRIP_STARTED
TRIP_COMPLETED
Message Queue（訊息佇列）：
Producer 把 Messages / Events 放入 Queue，再讓 Consumers
依自己的速度處理。
Location Service
↓
DRIVER_LOCATION_UPDATED
↓
Message Queue
↓
Trip Tracking Service
Producer（生產者）：
產生並送出 Message / Event 的 Component。
Consumer（消費者）：
接收 Message / Event 並執行工作的 Component。
例如：
Location Service
→ Producer
Trip Tracking Service
→ Consumer
Decoupling（解耦 / 降低耦合）：
讓 Components 不需要彼此緊密綁在一起才能工作。
Location Service
↓
Publish Event
↓
Multiple Consumers process independently
Idempotency（冪等性）：
同一個 Logical Operation 重複執行時，不應產生錯誤的重複結果。
例如：
TRIP_COMPLETED
因 Retry 被處理兩次，也不應因此讓 Payment 被重複收費。
Consistency（一致性） 在 Distributed System Context：
多個 Components / Copies 對同一份 Data 的 View 有多一致。
不同 Data 的 Requirement 不同。
Driver Map Location
→ 晚 500 ms 可能可以接受
Driver Assignment
→ 同一 Driver 不應成功分給兩個 Trips
Strong Consistency（強一致性）：
Read 希望看到最新且一致的結果。
Driver 已成功 Reservation 給 Passenger A 後，Passenger B
不應仍成功取得同一 Driver。
Eventual Consistency（最終一致性）
Eventual → 最終會達成的
意思：
不要求所有地方立刻看到完全相同 Data，但如果沒有新的
Update，經過一段時間後會逐漸收斂。
Driver Map 的短暫 Location 差異有時可以接受。
Hotspot（熱點）：
某個區域 / Resource 承受遠高於其他地方的 Traffic。
例如：
Concert ends
↓
50,000 passengers
↓
same area
↓
request rides
該區域就是 Geographic Hotspot。
Partition（分區）：
把大量 Data / Traffic 切成不同部分處理。
注意：
這裡是 Data / Workload Partitioning，不是 CAP Theorem 的 Network
Partition。
Geographic Partitioning（依地理區域分區）：
根據 Geographic Area 把 Data / Traffic 分到不同 Partitions。
例如概念上：
Boston
New York
Los Angeles
Taipei
但每個城市 Traffic 不一樣，因此仍要注意 Load Imbalance。
Sharding（分片）：
把大型 Dataset 分散到多個 Database / Storage Nodes。
可能依：
driver_id
region_id
geographic key
分散 Data。
Trade-off：
Routing
Rebalancing
Cross-Shard Query
Operational Complexity
所以不要一開始就盲目 Shard。
Shard Key（分片鍵）：
決定一筆 Data 應放在哪個 Shard 的 Key / Field。
選錯可能造成 Hot Shard。
Hot Shard（過熱分片）：
某個 Shard 承受遠高於其他 Shards 的 Traffic。
例如 Downtown 全在同一 Shard：
Shard A → overloaded
Shard B → idle
Shard C → idle
Cache（快取）：
把常用 Data 放在更快的位置，降低存取較慢 Source 的次數。
In-Memory（記憶體內）：
Data 主要存在 RAM 中，通常能提供很低的 Access Latency。
RAM = Random Access Memory
Random Access → 隨機存取
Memory → 記憶體
中文：
隨機存取記憶體
Current Driver Location 是高頻更新 Data，可能適合低延遲
Storage；但是否作為 Source of Truth 要依 Durability / Consistency
Requirement 決定。
Source of Truth（權威資料來源）：
System 判定某份 Data 最終正確狀態時所依賴的主要來源。
例如 Completed Trip Record 通常需要 Durable Storage。
Current Driver Location 則可能更偏向：
Freshness
+
Low Latency
Durability（持久性）：
已成功保存的重要 Data，不應因單一 Failure 輕易消失。
例如：
Completed Trip Record
通常比：
Driver 3 seconds ago 的 Location
更需要長期可靠保存。
Location History（位置歷史）：
一段時間內保存的過去 Location Records。
Retention（保留期限 / 保存策略）：
Data 要保存多久。
例如：
Current Location → latest state
Trip Record → long-term
Raw detailed location → depends on requirement
需要考慮 Cost、Privacy、Legal 與 Product Requirements。
Privacy（隱私）：
個人資訊應如何被合理收集、使用、保存與保護。
Location 是敏感 Data。
需要考慮：
Access Control
Retention
Encryption
Audit
Encryption（加密）：
使用 Key 把 Plaintext 轉成未授權者不容易理解的 Ciphertext。
Plaintext
↓
Encryption + Key
↓
Ciphertext
Encryption in Transit（傳輸中加密）：
in Transit → 正在傳輸途中
例如：
Driver App
↓ HTTPS
Backend
保護 Network 傳輸中的 Data。
Encryption at Rest（儲存中加密）：
at Rest → Data 已存在 Storage
用來保護 Database / Storage 中的 Sensitive Data。
API = Application Programming Interface
逐字：
Application → 應用程式
Programming → 程式設計
Interface → 介面
中文：
應用程式介面
API 定義 Software Components 如何溝通。
例如：
POST /drivers/location
POST /rides
GET /trips/{tripId}
Location Update 可以帶：
{
"latitude": 42.3,
"longitude": -71.1,
"timestamp": "2026-10-08T10:00:00Z"
}
Timestamp（時間戳記）：
表示 Data / Event 是在什麼時間產生的。
這很重要，因為 Network 可能讓 Events 亂序抵達。
Out-of-Order Event（順序錯亂事件）：
Events 抵達 Server 的順序和原本產生順序不同。
例如：
10:00:01 → Location A
10:00:02 → Location B
Server 卻收到：
B first
A later
如果無腦用「最後收到的」，Location 可能倒退。
Sequence Number（序號 / 順序編號）：
用可排序數值表示 Events 的 Logical Order。
例如：
Update #100
Update #101
Update #102
#100 即使較晚抵達，也能知道它比 #102 舊。
POST /drivers/location
{
"latitude": 42.3,
"longitude": -71.1,
"timestamp": "2026-10-08T10:00:00Z"
}
POST /rides
{
"pickup": {
"latitude": 42.3,
"longitude": -71.1
},
"destination": {
"latitude": 42.36,
"longitude": -71.0
}
}
Response：
{
"ride_id": "R123",
"status": "MATCHING"
}
假設：
1M online drivers
每個 Driver：
every 5 seconds
送一次 Location Update。
每秒：
1,000,000 / 5
=
200,000 updates/sec
Location Service 本身就是 High-Write System。
RPS = Requests Per Second
Requests → 請求
Per Second → 每秒
中文：
每秒請求數
如果每個 Location Update 是一個 Request：
≈ 200K RPS
QPS = Queries Per Second
Queries → 查詢
Per Second → 每秒
中文：
每秒查詢數
簡單區分：
RPS → Request Rate
QPS → Query Rate
一個 Request 可能造成多個 Queries。
Read-Heavy（讀取密集）：
Read Traffic 很高。
Write-Heavy（寫入密集）：
Write Traffic 很高。
Driver Location 不斷更新，因此 Location Workload 可能非常 Write-Heavy。
這會影響：
Storage Choice
Partitioning
Replication
Cache Strategy
Fan-Out（扇出）：
一個 Input 觸發多個 Downstream Operations。
例如：
One Ride Request
↓
Find many candidate drivers
↓
Potentially notify multiple candidates
因此不能只看 Ride Request RPS，還要看每個 Request 背後產生多少 Work。
Traffic Spike（流量尖峰）：
Traffic 在短時間內突然大幅增加。
例如：
Normal → 1K requests/sec
Concert ends → 20K requests/sec
System Design 要看 Peak，不只看 Average。
Backpressure（背壓 / 反壓）：
Downstream 處理速度跟不上 Incoming Traffic 時，System
讓上游減速、等待、排隊或限制流量。
可能手段：
Queue
Rate Limit
Reject
Slow Producer
Batch
要依 Requirement 選擇。
Rate Limiter（速率限制器）：
控制 Client / User / API 在一定時間內可以送多少 Requests。
例如 Buggy Driver App 不應該：
1000 location updates/sec
把 Backend 打爆。
Batch（批次）：
把多個小 Operations 合在一起處理。
某些 Analytics / History Processing 適合 Batch，但 Current Location
是否能 Batch，要看 Freshness Requirement。
SPOF = Single Point of Failure
Single → 單一
Point → 點
Failure → 故障
中文：
單點故障
如果只有一台 Location Service：
Server dies
↓
All driver updates stop
它就是 SPOF。
Health Check（健康檢查）：
定期檢查 Server / Component 是否能正常服務。
Load Balancer
↓
Server A → healthy
Server B → unhealthy
新 Requests 不再送給 B。
Observability（可觀測性）：
利用 Metrics、Logs、Traces 等 Signals 理解 System 內部狀態。
重要 Metrics：
Location Update RPS
Location Update Latency
Stale Update Rate
Matching Latency
Matching Success Rate
Reservation Conflict Rate
Active WebSocket Connections
Push Latency
Reconnect Rate
Trip Cancellation Rate
Invalid State Transition Rate
Reconnect（重新連線）：
Connection 中斷後重新建立 Connection。
Mobile Network 很容易切換：
Wi-Fi
↓
5G
↓
No Signal
↓
5G
所以不能假設 WebSocket 永遠不斷。
Missed Event（漏掉的事件）：
Client 斷線期間發生，但沒有即時收到的 Event。
例如：
Passenger disconnects
Driver:
A → B → C
Passenger reconnects
Location Tracking 可能只需要：
Latest Location = C
而不一定需要 Replay A、B、C。
這取決於 Event Type。
Latest State（最新狀態）：
Driver is currently at C
Event History（事件歷史）：
A → B → C
有些 Feature 只需要 Latest State；有些需要完整 History。
這會影響 Storage Design。
Authentication（身分驗證）：
確認「你是誰」。
例如：
Is this really Driver D123?
不能讓任意 Client 偽造 Driver Location。
Authorization（授權）：
確認已驗證的 User 是否有權限執行某 Action。
例如 Passenger A 不應讀取 Passenger B 的 Private Trip。
Audit Log（稽核紀錄 / 審計紀錄）：
記錄誰在什麼時間做了重要操作，方便追蹤與安全調查。
例如：
Who changed trip state?
When?
From what state?
To what state?
如果 Trip / Reservation 使用 Database Transaction，就會遇到 ACID。
ACID 是四個 Transaction Properties 的縮寫。
All or Nothing
→ 全部成功或全部失敗
不要只完成 Transaction 的一半。
Transaction 前後應維持已定義的 Data Rules / Constraints。
注意：Database 不會自動知道所有 Business Rules；仍需要
Constraints、Application Logic 與正確 Transaction Design。
Concurrent Transactions 要控制彼此干擾。
例如兩個 Passenger 同時搶 Driver X，需要適當的 Atomic Operation /
Locking / Transaction Design。
不同 Isolation Levels 能避免的問題不同，不能簡化成「有 ACID 就永遠沒有
Race Condition」。
COMMIT 成功後，資料應可靠保存。
例如 Trip Completed 並 COMMIT 後，Server Crash 不應讓 Trip Record 消失。
超簡單記：
A = Atomicity = 原子性
→ 做一半？不行。
C = Consistency = 一致性
→ 留下違反已定義規則的資料？不行。
I = Isolation = 隔離性
→ Concurrent Transactions 互相干擾？要控制。
D = Durability = 持久性
→ COMMIT 成功後資料卻消失？不行。
這兩個都叫 Consistency，但 Context 不同。
主要在 Transaction Context：
Data should remain within defined rules / invariants
主要在 Distributed System Context：
Different nodes should behave like they see one latest consistent value
所以：
ACID C ≠ CAP C
SLI = Service Level Indicator
Service → 服務
Level → 水準
Indicator → 指標
中文：
服務水準指標
是實際量測值。
例如：
Matching success rate = 99.95%
SLO = Service Level Objective
Service → 服務
Level → 水準
Objective → 目標
中文：
服務水準目標
例如：
99% of ride matching
should complete within 2 seconds
SLA = Service Level Agreement
Service → 服務
Level → 水準
Agreement → 協議
中文：
服務水準協議
通常是對 Customer 的正式服務承諾。
簡單記：
SLI → 實際量到多少
SLO → 希望達到多少
SLA → 正式承諾多少
Passenger App
│
↓
API / Load Balancer
│
┌────┼───────────────┐
↓ ↓ ↓
Ride Matching Trip
Service Service Service
│
↓
Geospatial Store
↑
│
Location Service
↑
│
Driver App
Real-Time Tracking：
Driver App
↓
Location Service
↓
Current Location Store
↓
Location Event
↓
Trip Tracking
↓
Connection Server
↓
Passenger App
Matching：
Passenger
↓
Ride Service
↓
Matching Service
↓
Geospatial Search
↓
Candidate Drivers
↓
ETA / Ranking
↓
Atomic Reservation
↓
Driver Offer
1. Driver App obtains Location
2. Create latitude / longitude / timestamp
3. Send to Location Service
4. Authenticate Driver
5. Validate Update
6. Ignore outdated update when appropriate
7. Update Current Driver Location
8. Publish DRIVER_LOCATION_UPDATED
9. Trip Tracking consumes Event
10. Push relevant latest location to Passenger
1. Passenger sends Ride Request
2. Ride Service creates ride_id
3. status = MATCHING
4. Matching Service reads Pickup Location
5. Geospatial Search finds nearby Available Drivers
6. Filter Candidates
7. Calculate Distance / ETA
8. Rank Candidates
9. Atomically reserve one Driver
10. Send Ride Offer
11. Driver accepts
12. Trip state → DRIVER_ASSIGNED
如果 Driver 拒絕：
Release reservation
↓
Try next candidate
如果 Driver 沒回：
Timeout
↓
Release reservation
↓
Try next candidate
不要一開始回答：
Redis + Kafka + WebSocket + NoSQL + Geohash
先問：
1. Need real-time driver location?
2. Need ride matching?
3. Need trip tracking?
4. Need payment?
5. Need surge pricing?
6. How many online drivers?
7. Ride requests per second?
8. Location update frequency?
9. Single city or global?
10. Required matching latency?
11. How fresh must location be?
12. What consistency does driver assignment require?
不要只回答：
Use Geohash.
完整思路：
1. Drivers report latitude / longitude
2. Store current available driver locations
3. Use Spatial Index / geographic partitioning
4. Search passenger cell + nearby cells
5. Filter unavailable drivers
6. Calculate more accurate distance / ETA
7. Rank candidates
8. Atomically reserve a driver
可以回答：
If the system has hundreds of thousands or millions of online drivers,
calculating the distance from every driver for every ride request is
expensive and unnecessary. A spatial index or geographic partitioning
strategy can narrow the search to relevant nearby areas first, then
the matching service can calculate more accurate distance or ETA for a
much smaller candidate set.
不要背：
Location = NoSQL
先分析 Access Pattern。
Current Driver Location：
Very frequent writes
Low latency
Geospatial query
Latest state important
Old state less important
Trip Record：
Durability
History
Structured data
Potential transaction requirements
所以：
不同 Data 可以有不同 Storage Design。
可以回答：
During an active trip, driver location changes frequently and the
passenger needs timely updates. Polling every few seconds is simple
but can generate many unnecessary requests. A WebSocket keeps a
long-lived bidirectional connection so the server can push relevant
location updates to the client. However, it also introduces connection
management, reconnect, scaling, and failure-handling complexity.
核心是：
Race Condition
不要只：
Read AVAILABLE
↓
Later write RESERVED
而是需要 Atomic Reservation：
Compare current state
↓
If still AVAILABLE
↓
Atomically change to RESERVED
只有一個 Operation 成功。
其他 Matching Request：
Reservation failed
↓
Try next candidate
不要回答全部 Strong 或全部 Eventual。
500 ms stale
可能仍可以接受。
same Driver assigned to two Trips
通常不能接受。
因此：
Consistency Requirement 應按照 Feature / Data Type 決定。
先辨認：
Traffic Spike
+
Geographic Hotspot
可能需要：
Horizontal Scaling
Geographic Partitioning
Load Balancing
Queue / Backpressure where appropriate
Hot Partition Monitoring
Capacity Headroom
最重要仍然是：
先找 Bottleneck，再選 Solution。
Requirements
□ Functional Requirement
□ Non-Functional Requirement
□ Low Latency
□ High Availability
Location
□ GPS
□ Latitude
□ Longitude
□ Coordinate
□ Geolocation
□ Geospatial Data
□ Location Update
□ Location Service
□ Frequency
□ Freshness
□ Stale Data
Ride / Matching
□ Ride Request
□ Pickup Location
□ Destination
□ Available Driver
□ Matching
□ Matching Service
□ Radius
□ Distance
□ Route
□ Routing
□ ETA
□ Candidate
□ Ranking
□ Criteria
Geospatial
□ Geospatial Search
□ Spatial Index
□ Geohash
□ Cell
□ Neighboring Cell
□ Precision
Concurrency
□ Race Condition
□ Shared Data
□ Atomic Operation
□ Compare-And-Set
□ Reservation
□ Timeout
□ Idempotency
Trip
□ State
□ State Transition
□ State Machine
Real-Time
□ Real-Time
□ Polling
□ WebSocket
□ Protocol
□ Bidirectional
□ Push
□ Connection
□ Connection Server
□ Connection Mapping
□ Reconnect
□ Missed Event
Events
□ Event
□ Message Queue
□ Producer
□ Consumer
□ Decoupling
Consistency
□ Strong Consistency
□ Eventual Consistency
□ ACID
□ CAP Consistency
Scaling
□ Hotspot
□ Partition
□ Geographic Partitioning
□ Sharding
□ Shard Key
□ Hot Shard
□ Cache
□ In-Memory
□ RAM
Data / Security
□ Source of Truth
□ Durability
□ Location History
□ Retention
□ Privacy
□ Encryption
□ Encryption in Transit
□ Encryption at Rest
□ Authentication
□ Authorization
□ Audit Log
API / Capacity
□ API
□ Timestamp
□ Out-of-Order Event
□ Sequence Number
□ RPS
□ QPS
□ Read-Heavy
□ Write-Heavy
□ Fan-Out
□ Traffic Spike
□ Backpressure
□ Rate Limiter
□ Batch
Reliability
□ SPOF
□ Health Check
□ Observability
Service Level
□ SLI
□ SLO
□ SLA
GPS
= Global Positioning System
= 全球定位系統
ETA
= Estimated Time of Arrival
= 預估抵達時間
API
= Application Programming Interface
= 應用程式介面
RAM
= Random Access Memory
= 隨機存取記憶體
RPS
= Requests Per Second
= 每秒請求數
QPS
= Queries Per Second
= 每秒查詢數
SPOF
= Single Point of Failure
= 單點故障
ACID
A = Atomicity = 原子性
C = Consistency = 一致性
I = Isolation = 隔離性
D = Durability = 持久性
SLI
= Service Level Indicator
= 服務水準指標
= 實際量測值
SLO
= Service Level Objective
= 服務水準目標
= 希望達成的目標
SLA
= Service Level Agreement
= 服務水準協議
= 對外正式服務承諾
Design Uber 的核心不是：
Passenger
↓
Database
↓
Driver
而是：
Drivers keep moving
↓
Frequent Location Updates
Need nearby drivers
↓
Geospatial Search + Spatial Index
Need best candidate
↓
Distance + ETA + Ranking
Two passengers may choose same driver
↓
Atomic Reservation + Concurrency Control
Trip has many stages
↓
State Machine
Driver keeps moving during trip
↓
Real-Time Updates
Need server-to-client updates
↓
Polling or WebSocket
Many events
↓
Message Queue / Event Processing when useful
Concert ends
↓
Traffic Spike + Geographic Hotspot
Different data needs different guarantees
↓
Choose Consistency based on Requirement
完整思考方式：
Requirement
↓
Estimate Scale
↓
Understand Access Pattern
↓
Find Bottleneck
↓
Choose Solution
↓
Understand Trade-off
↓
Measure
Design Uber 的核心不是背「Geohash + Redis + Kafka +
WebSocket」，而是理解為什麼移動中的 Driver 會產生大量 Location
Updates、為什麼 Nearby Search 需要 Geospatial Index、為什麼 Matching
會產生 Race Condition，以及為什麼不同 Data 對 Consistency、Freshness
與 Durability 有不同要求。
Day 25｜AI System Design 入門：LLM、Token、Context
Window、Inference、Embedding 到底是什麼？
會從最基礎開始：
AI
ML
Deep Learning
Neural Network
LLM
GPT
Token
Tokenizer
Prompt
Context Window
Inference
Training
Parameter
Embedding
Vector
Semantic Similarity
Vector Database
GPU
Batching
Streaming Response
Hallucination
Temperature
RAG
例如：
LLM
= Large Language Model
= 大型語言模型
RAG
= Retrieval-Augmented Generation
= 檢索增強生成
也會繼續按照：
完整英文
↓
每個字的中文
↓
整體中文意思
↓
它是什麼
↓
為什麼需要
↓
簡單例子
↓
System Design 用法
再進入 Architecture。
iThome鐵人賽
看影片追技術