Thiết kế hệ thống cơ bản (1/10): Học System Design — metric, QPS, CAP

Khóa System Design cơ bản — scale từ 1 → 1.000.000 người dùng — Phần 1/10 (~18 phút)
Case study xuyên suốt: ShortLink (rút gọn URL, redirect, đếm click).
Bản đồ học: Học System Design cơ bản từ đâu · Hub: Khóa 10 phần
Tiếp theo: Phần 2 — 1 người dùng, monolith

Bạn không cần biết trước distributed systems. Bạn cần: hiểu HTTP cơ bản, API, và database quan hệ ở mức CRUD.

---

Mục lục

1. System design trả lời câu hỏi gì?
2. Functional vs non-functional
3. Metric vận hành
4. Back-of-envelope: ShortLink
5. CAP — phiên bản thực dụng
6. Component map — bức tranh toàn khóa
7. Bài tập
8. FAQ ôn tập

---

System design trả lời câu hỏi gì?

Một buổi thiết kế tốt không bắt đầu bằng “em dùng Kafka”. Thứ tự hợp lý:

1. Clarify — ai dùng, feature v1, giới hạn (mobile/web, đăng nhập hay không).
2. Estimate — bao nhiêu user, read/write ratio, dung lượng lưu trữ 3 năm.
3. API & data model — endpoint chính, bảng/collection cốt lõi.
4. High-level diagram — client → edge → app → cache → DB.
5. Bottleneck — chỗ nào chết trước khi scale tiếp.
6. Deep dive — chỉ 1–2 phần quan trọng (cache, shard, queue…).

Output mong đợi: sơ đồ có tên component, con số giả định minh bạch, trade-off nói rõ.

---

Functional vs non-functional

Loại	Ví dụ ShortLink v1
Functional	Tạo slug, redirect 302/301, tăng click count, dashboard list link
Non-functional	p99 redirect < 100ms; 99.9% uptime; chịu peak redirect; data không mất

Nguyên tắc scale: chỉ thêm complexity khi metric hoặc SLO (Service Level Objective) bị vi phạm — không “microservices sớm”.

---

Metric vận hành

Metric	Ý nghĩa	Ghi chú
DAU / MAU	Người dùng active	MAU thường lớn hơn DAU
QPS / RPS	Request/giây	Luôn thiết kế cho peak, không average
p50 / p95 / p99 latency	Phân vị độ trễ	SLO hay gắn p99
Availability	% uptime	99.9% ≈ 8.7 giờ downtime/năm
Error rate	% 5xx	Alert khi vượt ngưỡng

Read vs write: ShortLink thường read-heavy (redirect >> tạo link). Tỷ lệ 100:1 hoặc 1000:1 là bình thường.

---

Back-of-envelope: ShortLink

Giả định: 1 triệu MAU, 30% DAU → 300.000 DAU.

• Mỗi user active: 5 redirect/ngày + 0,2 link tạo/ngày.
• Redirect/day: 300k × 5 = 1,5M → average ~17 RPS (1,5M / 86400).
• Peak ×10: ~170 RPS redirect (số nhỏ; peak thật có thể cao hơn nếu link viral).
• Create link: 300k × 0,2 = 60k/ngày → ~0,7 write RPS average.

Storage (3 năm): 60k link/ngày × 365 × 3 ≈ 65M rows. Mỗi row ~500 byte → ~32 GB (chưa index, chưa log click chi tiết).

Khi viral một slug: hot key — một redirect có thể lên hàng nghìn RPS trên một bản ghi → đó là lý do cache ở phần 4.

---

CAP — phiên bản thực dụng

• Consistency — mọi client thấy cùng giá trị tại “cùng logical time”.
• Availability — request nhận response (success/fail rõ ràng), không treo vô hạn.
• Partition tolerance — mạng giữa máy có thể đứt; thực tế luôn có P.

Trong partition, bạn chọn CP (giữ consistency, có thể từ chối) hoặc AP (phản hồi, chấp nhận stale).

Dữ liệu ShortLink	Gợi ý
Slug → URL khi tạo	Strong consistency trên primary
Click count dashboard	Eventual consistency — trễ vài giây OK
Redirect sau khi sửa URL	Cache TTL ngắn + invalidate

---

Component map — bức tranh toàn khóa

[1 user]     Monolith + DB local
[~100]       App VM + Managed DB + backup
[~1K]        + Redis + CDN + rate limit
[~10K]       + Read replica + index tuning
[~100K]      + Load balancer + N app + Redis cluster
[~500K]      + Message queue + tách redirect/analytics
[~1M]        + Sharding + multi-region edge + SLO/DR

Mỗi phần trong khóa đi một bậc — có bảng component, sơ đồ ASCII, và bài tập.

---

Bài tập

1. Với app của bạn (hoặc ShortLink), liệt kê 3 functional và 3 non-functional requirements.
2. Ước lượng QPS average và peak nếu MAU = 100.000, mỗi user 10 read/ngày, peak ×5.
3. Phân loại: slug lookup, click count, session login — CP hay AP?

---

FAQ ôn tập

Xem frontmatter FAQ cuối trang — phần tiếp theo triển khai monolith một máy cho đúng 1 user (MVP).

---

Điều hướng seri: Phần 2 →