Day 18 我們學到 System Design Interview 的基本流程，其中一個重要步驟是：
Estimate Scale
很多初學者看到這裡會開始緊張：
100M Users 到底是多少？
一天有幾秒？
KB、MB、GB 怎麼換？
RPS 怎麼算？
Storage 怎麼估？
Bandwidth 怎麼算？
Cache 要多大？
但 System Design Interview 的 Estimation 通常不是高等數學。
真正想看的比較像是：
你能不能用簡單的數字，快速判斷 System 大概有多大。
今天從最基本的單位開始。
Back-of-the-Envelope Estimation：
使用簡單的 Assumption 和基本計算，快速估出 System 的大概規模。
字面意思是：
在信封背面快速算一下
它強調：
快速
合理
量級正確
Assumption 清楚
而不是追求 100% 精準。
Estimation：
根據已知資訊與合理假設，推算一個接近實際情況的數字。
Measurement：
透過實際觀察或工具得到的測量結果。
例如：
Production Monitoring:
Current RPS = 12,483
這是 Measurement。
如果 Interview 沒有 Production Data：
Assume average RPS ≈ 12K
這是 Estimation。
Architecture 應該跟 Scale 有關。
100 Requests/day
和：
100 Billion Requests/day
顯然不是同一種問題。
Estimation 的目的不是炫耀數學，而是回答：
這個 System 到底有多大？
Quantity：
數量。
例如：
100 Users
5 GB
10K RPS
Unit：
描述這個數值代表什麼的單位。
例如：
100 MB
100 RPS
100 ms
意思完全不同。
所以計算時一定要注意 Unit。
Bit：
Binary Digit，可以表示 0 或 1。
Binary：
只使用兩種值表示資訊的系統。
Computer 常使用：
0
1
Byte：
8 Bits。
所以：
1 Byte = 8 bits
通常：
b = bit
B = Byte
所以 Mb 和 MB 並不是同一個單位。
System Design 快速估算常使用：
1 KB ≈ 1,000 Bytes
1 MB ≈ 1,000 KB
1 GB ≈ 1,000 MB
1 TB ≈ 1,000 GB
1 PB ≈ 1,000 TB
也就是：
KB ≈ 10^3 Bytes
MB ≈ 10^6 Bytes
GB ≈ 10^9 Bytes
TB ≈ 10^12 Bytes
PB ≈ 10^15 Bytes
PB = Petabyte。
Binary-based Units 還有：
1 KiB = 1024 Bytes
1 MiB = 1024 KiB
1 GiB = 1024 MiB
但 System Design 快速估算常使用 1000，因為容易心算。
重點是知道：
這是一個 Approximation。
Approximation：
近似值。
例如：
1 day = 86,400 seconds
快速估算可以寫：
≈ 100,000 seconds
≈ 100K seconds
這樣很多計算會非常簡單。
K = Thousand
M = Million
B = Billion
所以：
1K = 1,000 = 10^3
1M = 1,000,000 = 10^6
1B = 1,000,000,000 = 10^9
Order of Magnitude：
數值大概落在哪個 10 的次方等級。
System Design 常在乎：
1K RPS？
100K RPS？
10M RPS？
而不是：
1,157 vs 1,162 RPS
很值得記：
1 minute = 60 seconds
1 hour = 3,600 seconds
1 day = 86,400 seconds
快速估算：
1 day ≈ 100K seconds
因此：
100K operations/day ≈ 1/sec
1M/day ≈ 10/sec
10M/day ≈ 100/sec
100M/day ≈ 1K/sec
1B/day ≈ 10K/sec
RPS = Requests Per Second
每秒多少 Request。
QPS = Queries Per Second
每秒多少 Query / Operation。
簡化：
RPS → API / HTTP Requests
QPS → Query / Operation Rate
不同 Team 可能略有不同用法。
Throughput：
System 在一段時間內可以處理多少工作。
例如：
10K Requests/sec
1K Messages/sec
500 Orders/sec
Latency：
一個 Operation 從開始到完成需要多久。
Throughput：
一段時間能完成多少 Operations。
餐廳類比：
Latency
→ 一份餐點要等多久
Throughput
→ 餐廳一小時能做多少份餐
假設：
100M Requests/day
精確一些：
100,000,000 / 86,400
≈ 1,157 RPS
快速估算：
100M / 100K
≈ 1K RPS
所以：
Average RPS ≈ 1K
Average：
平均值。
但 Real Traffic 通常不平均。
例如：
3 AM → 300 RPS
8 PM → 5,000 RPS
Peak Traffic：
Traffic 最高時段的負載。
如果只按照 Average Capacity 設計，Peak 時可能 Overload。
如果沒有真實 Production Data，可以假設：
Peak = 5 × Average
這個 5× 可以稱為：
Peak Factor
例如：
Average = 1K RPS
Peak Factor = 5
Peak ≈ 5K RPS
Peak Factor 沒有固定答案。Interview 中要說清楚它是 Assumption。
Burst：
短時間突然出現的大量 Traffic。
例如平常：
1K RPS
突然：
50K RPS for 30 seconds
這就是 Traffic Burst。
假設：
DAU = 10M
20 Requests/User/Day
每天：
10M × 20
=
200M Requests/day
Average：
200M / 100K
≈ 2K RPS
Peak Factor = 5：
Peak ≈ 10K RPS
假設：
Read : Write = 100 : 1
代表每 100 Reads 大約只有 1 Write。
如果 Total Traffic 約 10K RPS，可以粗略理解：
Reads ≈ almost 10K RPS
Writes ≈ around 100 RPS
Read-heavy：
Read Operations 遠多於 Write。
常見思考：
Cache
Read Replica
CDN
Write-heavy：
Write Operations 很頻繁。
常見思考：
Write Throughput
Queue
Partitioning
Sharding
Batching
Batch：
一批資料。
Batching：
把多個小 Operations 集合起來，一次處理。
例如：
100 Events
↓
One Batch
↓
Database
可能：
Reduce overhead
Improve throughput
Trade-off：
可能增加等待時間
Failure Handling 更複雜
Storage：
System 用來保存 Data 的空間。
Record：
Database 裡的一筆資料。
Record Size：
一筆 Record 大約佔多少 Storage。
例如：
1 URL Record ≈ 500 Bytes
最基本公式：
Storage
=
Number of Records
×
Average Record Size
Growth：
成長量。
Daily Storage Growth：
每天新增多少 Storage。
例如：
10M Records/day
×
500 Bytes
=
5 GB/day
Retention：
Data 要保存多久。
例如：
Logs → 30 days
Analytics → 1 year
Messages → indefinitely
如果：
5 GB/day
×
365 days
≈
1.8 TB
Policy：
System 定義的一組規則。
Retention Policy：
規定某類 Data 保存多久，以及到期後怎麼處理。
不同 Data 可能有不同 Retention Requirements。
Raw Data：
還沒有加入 Index、Replication、Backup 等額外成本的原始 Data Size。
Overhead：
為了讓 System 正常運作而額外付出的資源成本。
例如：
Indexes
Metadata
Replication
Transaction Logs
都可能增加 Storage。
如果同一份 Data 保存 3 Copies：
Replication Factor = 3
Replication Factor：
同一份 Data 總共保存多少 Copies。
粗略：
Physical Storage
≈
Raw Data × Replication Factor
例如：
1 TB × 3
=
3 TB
還沒包含其他 Overhead。
Logical Storage：
從 Application 角度看真正 Data 的大小。
Physical Storage：
Infrastructure 實際使用的 Storage。
例如：
Logical = 1 TB
加上：
Replication
Index
Backup
Metadata
Physical Storage 可能遠大於 1 TB。
Bandwidth：
一段時間內可以傳輸多少 Data。
道路類比：
Latency
→ 一台車到目的地花多久
Bandwidth
→ 一段時間可以讓多少車通過
基本估算：
Bandwidth
≈
RPS × Average Data Size
例如：
10K RPS
×
100 KB
=
1 GB/sec
Ingress：
進入 System 的 Data Traffic。
例如 User Upload Photo。
Egress：
離開 System 的 Data Traffic。
例如 Server 把 Photo 傳給 User。
Image / Video Platform 的 Egress 可能非常大，因此 CDN 很重要。
Mbps
= Megabits per second
MB/s
= Megabytes per second
因為：
1 Byte = 8 bits
所以忽略其他 Overhead：
80 Mbps
≈
10 MB/s
Network Overhead：
除了真正 Application Data 外，Network Communication
額外需要傳輸的資訊。
例如：
Protocol Headers
Encryption-related Data
Connection Information
Interview 粗估通常可以先忽略，除非題目需要精細分析。
Memory：
Computer 用來快速保存正在使用中的 Data 的資源。
一般可先理解為 RAM。
和 Disk 相比：
Memory
→ 通常更快
→ 通常更貴
→ 容量通常較小
Redis 主要使用 Memory，所以 Cache Size 很重要。
假設：
100M URL Records
只 Cache 最熱門：
20%
每筆：
500 Bytes
所以：
100M × 20%
=
20M Records
Raw Cache Data：
20M × 500 Bytes
=
10 GB
實際 Redis Memory 還會有 Data Structure Overhead。
Working Set：
某段時間內 Application 真正常被使用的那一部分 Data。
例如 DB 有：
1B URLs
但每天真正熱門只有：
20M
這 20M 可能就是 Hot Working Set。
Cache 不一定要裝整個 Database。
Cache Hit Rate：
Request 可以直接從 Cache 找到 Data 的比例。
例如：
100 Requests
90 Hits
Hit Rate：
90%
Cache Miss Rate：
Cache 找不到 Data 的比例。
所以：
Miss Rate = 10%
簡化：
Hit Rate + Miss Rate = 100%
假設：
100K Read RPS
Cache Hit Rate = 95%
Miss：
5%
DB Load：
100K × 5%
=
5K RPS
所以：
Without Cache → 100K DB RPS
With Cache → 5K DB RPS
這就是 Estimation 如何幫助 Architecture Reasoning。
CPU = Central Processing Unit
Server 執行計算工作的主要處理器。
Benchmark：
使用固定方式測量 Component Performance 的測試。
例如：
One Server
≈ 2K RPS
at acceptable latency
如果 Peak：
10K RPS
理想化至少：
10K / 2K
=
5 Servers
但 Production 通常不會剛好只準備 5 台。
Headroom：
額外保留的 Capacity，用來處理 Traffic Spike、Failure 或 Estimation
Error。
Utilization：
資源目前被使用了多少比例。
例如：
CPU Utilization = 70%
如果長期：
99%
幾乎沒有 Headroom，Traffic 稍微增加就可能出問題。
Capacity Planning：
根據預期 Traffic、Growth 與 Reliability Requirement，規劃需要多少
Compute、Storage、Network Resources。
Estimation 是 Capacity Planning 的基礎之一。
Growth Rate：
某個 Quantity 隨時間增加的速度。
例如：
Users +10% / month
Storage +5 TB / month
Traffic doubles / year
Design 不只看今天，也要想未來。
Linear Growth：
每個時間單位增加固定數量。
例如：
10 TB
15 TB
20 TB
25 TB
每次 +5 TB。
Exponential Growth：
以固定比例成長，成長量本身也會變大。
例如每年翻倍：
1 TB
2 TB
4 TB
8 TB
Safety Margin：
為了應付估算誤差或意外情況而保留的安全空間。
例如估：
Storage = 100 TB
不一定只準備剛好 100 TB。
Headroom 常偏向運行 Capacity；Safety Margin 是更廣泛的安全餘裕概念。
假設：
10M new URLs/day
1B redirects/day
Write：
10M / 100K
≈ 100 writes/sec
Read：
1B / 100K
≈ 10K reads/sec
所以：
Read : Write
≈ 100 : 1
這是一個非常 Read-heavy 的 System。
假設：
Average Read = 10K RPS
Peak Factor = 5
Peak：
50K RPS
因此要開始考慮：
Load Balancer
Multiple Backend Servers
Cache
Database Read Capacity
10M URLs/day
×
500 Bytes
=
5 GB/day
一年：
≈ 1.8 TB Raw Data
5 年：
≈ 9 TB
Replication Factor = 3：
9 TB × 3
=
27 TB
還沒包含 Index、Backup、Metadata。
Peak：
50K Read RPS
Hit Rate：
95%
DB：
50K × 5%
=
2.5K RPS
所以高 Hit Rate 的 Cache 可以大幅降低 DB Read Load。
假設：
DAU = 50M
40 Messages/User/Day
每天：
50M × 40
=
2B Messages/day
Average：
2B / 100K
≈ 20K Messages/sec
Peak Factor = 5：
≈ 100K Messages/sec
每個 Message：
500 Bytes
每天：
2B × 500 Bytes
≈ 1 TB/day
一年：
≈ 365 TB Raw Data
Replication Factor = 3：
≈ 1.1 PB
看到這個 Scale，就會開始問：
Retention？
Partition Key？
Write Throughput？
Sharding？
Old Messages 怎麼保存？
假設：
10M Photos/day
Average Photo = 3 MB
每天：
10M × 3 MB
=
30 TB/day
一年：
≈ 11 PB/year
這時會自然想到：
Object Storage
CDN
Metadata Database
Binary Object：
Image、Video、Audio、PDF 等以 Binary Data 儲存的檔案。
例如：
.jpg
.png
.mp4
.pdf
Object Storage：
專門保存 File / Object 類型 Data 的 Storage System。
例如：
Images
Videos
Documents
Backups
Database 可以保存：
photo_id
owner_id
object_url
created_at
真正 Photo Binary 放 Object Storage。
假設：
100M photo views/day
Average delivered image = 1 MB
每天：
100M MB
≈ 100 TB/day Egress
這時 CDN 可以：
User
↓
CDN
↓ Cache Miss
Origin / Object Storage
降低 Origin Traffic。
Compression：
使用方法減少 Data Size。
例如：
Original = 8 MB
Compressed = 2 MB
可以降低：
Storage
Bandwidth
Download Time
Trade-off 可能是：
CPU Cost
Quality Loss
Processing Complexity
Compression Ratio：
描述壓縮前後 Data Size 的關係。
因為不同地方定義方式可能不同，面試中最清楚的方法是直接說：
10 MB → 2 MB
避免 Ratio 定義混淆。
假設：
1M videos/day
Average Video = 100 MB
每天 Original：
1M × 100 MB
=
100 TB/day
但 Video Platform 通常還會產生：
360p
720p
1080p
等版本。
Resolution：
Image / Video 畫面的像素尺寸或清晰度等級。
例如：
360p
720p
1080p
4K
通常 Resolution 越高，Data Size 與 Bandwidth Requirement 也可能越高。
Transcoding：
把 Video 從一種 Encoding / Quality / Format 轉成另一種版本。
例如：
Original
↓
360p
720p
1080p
讓不同 Network Condition 的 User 使用不同版本。
Derived Data：
從原始 Data 經過 Processing 產生的新 Data。
例如 Transcoding 產生的 360p、720p、1080p 都是 Derived Data。
Amplification：
某個因素讓原本的量被放大。
Storage Amplification：
Replication、Index、Derived Data 等讓實際 Storage 比 Raw Data 大。
所以：
Raw Video = 100 TB/day
不代表 Physical Storage 只需要 100 TB/day。
例如 Search：
Request:
"iphone"
→ very small
Response:
100 Products
→ much larger
所以 Bandwidth 可以分：
Inbound Request Size
Outbound Response Size
Read Amplification：
User 的一個 Read，內部可能造成多次 Storage / Service Reads。
例如：
GET /home
內部：
Read User
Read Posts
Read Recommendations
Read Notifications
所以：
External RPS
≠
Database QPS
Write Amplification：
Application 的一個 Write，內部可能造成多次實際 Writes。
例如：
Create Order
可能：
Write Order
Write Items
Update Inventory
Write Audit Log
Publish Event
所以：
1 API Write
≠
1 Storage Write
Fan-out：
一個 Input / Event 被展開成多個 downstream Operations。
例如：
New Post
↓
Notify 1,000 Followers
1 個 Post 可能產生 1,000 Notification Operations。
假設：
1K Posts/sec
×
500 Followers
=
500K downstream operations/sec
所以不能只看 Frontend RPS。
Concurrent：
同一段時間內同時存在或進行。
Concurrent Users：
同一時間正在使用 System 的 User 數量。
例如：
DAU = 10M
不代表 10M Users 同時在線。
可能：
Concurrent Users = 500K
這對 Chat、Gaming、Live System 很重要。
Connection：
Client 與 Server 之間建立的 Communication Relationship。
例如：
TCP Connection
WebSocket Connection
Database Connection
如果 Chat System 有：
5M Concurrent Users
每人 1 WebSocket：
≈ 5M concurrent connections
即使 Messages/sec 不高，Infrastructure 仍要維持這些 Connections。
WebSocket：
一種讓 Client 與 Server 建立長時間、雙向 Communication Channel 的
Protocol。
常見：
Chat
Live Updates
Online Games
Real-time Dashboard
後面 Chat System Design 再深入。
Cost Estimation：
根據 Storage、Bandwidth、Compute 等資源估算運行 System 的成本。
Cloud Price 會依 Provider、Region、Service、Discount 改變。
Interview 通常不要求背價格。
重點是：
Architecture Decision
→ 會影響 Cost
Unit Economics：
從單一 User、Request、Order 等單位理解收入或成本。
例如 AI Service：
$0.10 / Report
×
1M Reports/day
=
$100K/day
這時 Rate Limiting、Caching、Model Selection 也可能是 Cost Problem。
False Precision：
原始資料並不精確，卻用很多小數位讓結果看起來過度精準。
例如 Assumption 都是粗略的，卻回答：
2,314.814814 RPS
通常沒有必要。
更適合：
≈ 2K RPS
Sanity Check：
快速檢查結果是否合理，避免明顯算錯。
例如：
1M Users × 1 MB
應該大約：
1 TB
如果算出 1 PB，就應該重新檢查。
Cross-check：
用另一種方法重新驗證結果。
例如：
10M × 100 Bytes
方法 A：
10^7 × 10^2
=
10^9 Bytes
≈ 1 GB
方法 B：
100 Bytes × 10M
≈ 1,000M Bytes
≈ 1 GB
兩個結果接近。
1. Clarify Requirements
2. Estimate Users
3. Estimate Requests
4. Convert to RPS
5. Estimate Peak
6. Separate Read / Write
7. Estimate Record / Object Size
8. Estimate Storage Growth
9. Estimate Retention
10. Estimate Bandwidth if relevant
11. Estimate Cache / Memory if relevant
12. Add Replication / Overhead
13. Consider Growth
14. Sanity Check
不是每一題都需要全部計算。
例如：
YouTube
Netflix
Instagram Photos
Cloud Storage
Video Conference
因為 Object 很大，Network Traffic 可能是核心 Bottleneck。
例如：
Chat
WebSocket Service
Online Gaming
Live Collaboration
這時只算 RPS 可能不夠。
例如：
Photo Storage
Video Platform
Logging
Analytics
Chat History
Cloud Drive
要關注：
Daily Growth
Retention
Replication
例如：
Since the exact traffic isn't specified, I'll assume 10 million daily
active users.
或：
For a rough estimate, I'll approximate one day as 100,000 seconds.
或：
I'll assume peak traffic is around five times the average.
這讓面試官知道：
Assumption ≠ Fact
Cheat Sheet：
把常用資訊濃縮成方便快速查看的小抄。
Time
----
1 min = 60 sec
1 hour = 3,600 sec
1 day = 86,400 sec
≈ 100K sec
Numbers
-------
1K = 10^3
1M = 10^6
1B = 10^9
Storage
-------
1 KB ≈ 10^3 Bytes
1 MB ≈ 10^6 Bytes
1 GB ≈ 10^9 Bytes
1 TB ≈ 10^12 Bytes
1 PB ≈ 10^15 Bytes
Traffic Shortcut
----------------
100K/day ≈ 1/sec
1M/day ≈ 10/sec
10M/day ≈ 100/sec
100M/day ≈ 1K/sec
1B/day ≈ 10K/sec
Bandwidth
---------
Bandwidth
≈ RPS × Average Payload Size
Storage
-------
Storage
≈ Records × Record Size × Retention
Replication
-----------
Physical Storage
≈ Raw Storage × Replication Factor
100M / 100K
≈ 1K RPS
再補：
This is average traffic.
Peak traffic can be several times higher.
1M × 1 KB
≈ 1 GB Raw Data
實際 Storage 還要考慮 Index、Replication、Metadata、Backup。
Miss Rate = 10%
DB Read Load
=
100K × 10%
=
10K RPS
10 TB × 3
=
30 TB
還沒算其他 Overhead。
5M × 4 MB
=
20 TB/day
一年：
≈ 7.3 PB/year
看到這個 Scale，自然會想到 Object Storage、CDN、Compression 與
Retention。
Users
□ DAU?
□ MAU?
□ Concurrent Users?
Traffic
□ Requests/User/Day?
□ Requests/Day?
□ Average RPS?
□ Peak Factor?
□ Peak RPS?
□ Read / Write Ratio?
□ Burst?
Storage
□ Records/Day?
□ Average Record Size?
□ Daily Growth?
□ Retention?
□ Raw Storage?
□ Replication Factor?
□ Index / Metadata / Backup Overhead?
Network
□ Request Size?
□ Response Size?
□ Ingress?
□ Egress?
□ Bandwidth?
Cache
□ Working Set?
□ Cache Size?
□ Hit Rate?
□ Miss Rate?
□ DB Load after Cache?
Reliability
□ Headroom?
□ Safety Margin?
Growth
□ Growth Rate?
□ 1 year?
□ 5 years?
Validation
□ Units correct?
□ Approximation clear?
□ Assumptions stated?
□ Sanity Check?
□ Avoid False Precision?
1. Back-of-the-Envelope Estimation？
2. Estimation vs Measurement？
3. Quantity / Unit？
4. Bit / Binary / Byte？
5. 1 Byte 有幾 Bits？
6. KB / MB / GB / TB / PB？
7. KiB / MiB / GiB？
8. Approximation？
9. K / M / B？
10. Order of Magnitude？
11. 一天有幾秒？
12. 為什麼可近似 100K sec/day？
13. RPS / QPS？
14. Throughput？
15. Throughput vs Latency？
16. Average RPS？
17. Peak Traffic？
18. Peak Factor？
19. Burst？
20. Read / Write Ratio？
21. Read-heavy / Write-heavy？
22. Batching？
23. Storage / Record Size？
24. Daily Storage Growth？
25. Retention / Retention Policy？
26. Raw Data / Overhead？
27. Replication Factor？
28. Logical vs Physical Storage？
29. Bandwidth？
30. Ingress / Egress？
31. Mbps vs MB/s？
32. Network Overhead？
33. Memory？
34. Cache Size？
35. Working Set？
36. Cache Hit / Miss Rate？
37. Hit Rate 如何影響 DB Load？
38. CPU / Benchmark？
39. Headroom / Utilization？
40. Capacity Planning？
41. Growth Rate？
42. Linear vs Exponential Growth？
43. Safety Margin？
44. Binary Object？
45. Object Storage？
46. Compression？
47. Resolution / Transcoding？
48. Derived Data？
49. Storage Amplification？
50. Read Amplification？
51. Write Amplification？
52. Fan-out？
53. Concurrent Users？
54. Connection Capacity？
55. WebSocket？
56. Cost Estimation？
57. Unit Economics？
58. False Precision？
59. Sanity Check / Cross-check？
60. 100M Requests/day 大約多少 RPS？
61. 1M × 1 KB 大約多少 Storage？
62. 100K RPS、95% Hit Rate，DB 約多少 RPS？
63. 10 TB、Replication Factor 3，需要多少 Storage？
Back-of-the-Envelope Estimation 的核心不是：
算得非常精準
而是：
快速建立 Scale 的直覺，幫助 Architecture Decision。
最值得記：
1 day
= 86,400 sec
≈ 100K sec
1K = 10^3
1M = 10^6
1B = 10^9
1 KB ≈ 10^3 Bytes
1 MB ≈ 10^6 Bytes
1 GB ≈ 10^9 Bytes
1 TB ≈ 10^12 Bytes
1 PB ≈ 10^15 Bytes
核心公式：
Average RPS
≈ Requests/day ÷ seconds/day
Peak RPS
≈ Average RPS × Peak Factor
Storage
≈ Records × Record Size × Retention
Bandwidth
≈ RPS × Average Data Size
DB Read Load after Cache
≈ Read RPS × Cache Miss Rate
真正的流程：
Estimate
↓
Understand Scale
↓
Find Bottleneck
↓
Choose Solution
↓
Understand Trade-off
Estimation 的價值不在數學本身，而是讓你知道 Architecture
到底需要解決多大的 Problem。
下一篇開始真正把前面學到的 Building Blocks 組合成完整 System：
Day 20｜Design URL Shortener：從 Requirement 到 Billion-scale
Redirect System
會完整走過：
Functional Requirements
Non-Functional Requirements
Capacity Estimation
API Design
Data Model
Short Code Generation
Collision
Base62
Cache
Database
Replication
Sharding
Hot Key
Expiration
Analytics
Reliability
Security
Trade-offs
每一個新名詞仍然會先用初學者能理解的方式解釋，再放進 Architecture。
iThome鐵人賽
看影片追技術