1. System Design là gì?
System design là quá trình định nghĩa kiến trúc, component, interface và data flow của một hệ thống phần mềm để đáp ứng
một tập requirement (functional + non-functional). Khác lập trình algorithm (DSA) — system design quan tâm:
- Quy mô — hệ thống phải xử lý bao nhiêu user, request, data?
- Latency — bao nhanh user nhận response?
- Reliability — chấp nhận downtime bao nhiêu?
- Cost — server, storage, bandwidth tốn bao nhiêu?
- Trade-off — không có "best", chỉ có "phù hợp với context".
"Có 2 loại hệ thống: hệ thống chưa gặp scale, và hệ thống đang vỡ vì scale."
2. Các metric cốt lõi
2.1. Latency vs Throughput
| Metric | Định nghĩa | Đơn vị |
|---|
| Latency | Thời gian xử lý 1 request | ms (mili-giây) |
| Throughput | Số request xử lý/giây | QPS / RPS / TPS |
| Bandwidth | Lưu lượng data | Mbps / Gbps |
Latency và throughput không cùng nhau. Tăng concurrency → throughput tăng nhưng latency có thể tăng theo (queuing).
2.2. Phần trăm latency — P50, P95, P99
Latency trung bình (mean) là metric tệ vì bị skew bởi outlier. Dùng percentile:
- P50 (median) — 50% request nhanh hơn giá trị này.
- P95 — 95% nhanh hơn. Quan tâm "average user experience".
- P99 — 99% nhanh hơn. Quan tâm "worst-case acceptable".
- P99.9 — 1/1000 request có thể chậm hơn. Quan trọng với SaaS lớn.
Mục tiêu thực tế: P99 < 500ms cho web app, < 100ms cho API quan trọng.
2.3. Availability — "9 con số"
| Availability | Downtime/năm | Downtime/tháng |
|---|
| 99% (2 nines) | 3.65 ngày | 7.2 giờ |
| 99.9% (3 nines) | 8.76 giờ | 43.8 phút |
| 99.99% (4 nines) | 52.6 phút | 4.32 phút |
| 99.999% (5 nines) | 5.26 phút | 25.9 giây |
Mỗi "9" thêm — chi phí tăng 10×. Cân nhắc thực tế.
3. Bốn nguyên lý cốt lõi
┌────────────────────────────────────────────────────┐
│ FOUR PRINCIPLES OF SYSTEM DESIGN │
├────────────────────────────────────────────────────┤
│ │
│ 1. SCALABILITY │
│ Khi load tăng 10×, hệ vẫn hoạt động trơn tru │
│ │
│ 2. RELIABILITY (FAULT TOLERANCE) │
│ 1 component chết, hệ vẫn chạy │
│ │
│ 3. AVAILABILITY │
│ Tỉ lệ thời gian hệ hoạt động │
│ │
│ 4. PERFORMANCE │
│ Latency đáp ứng SLA │
│ │
└────────────────────────────────────────────────────┘
4 nguyên lý này thường đối nghịch nhau. Ví dụ: Sync replication tăng reliability, giảm performance. Microservice tăng scalability nhưng giảm reliability tổng (nhiều hop, nhiều SPOF tiềm tàng).
4. Building Blocks phổ biến
┌────────────────────────────────────────────────────────────┐
│ SYSTEM DESIGN BUILDING BLOCKS │
└────────────────────────────────────────────────────────────┘
┌─ EDGE LAYER ───────────────────────────────────────┐
│ CDN · WAF · DDoS protection │
│ Edge cache (CloudFlare, AWS CloudFront) │
└────────────────────────────────────────────────────┘
│
▼
┌─ ENTRY LAYER ──────────────────────────────────────┐
│ Load Balancer (L4/L7) │
│ API Gateway · Reverse Proxy (nginx) │
│ Rate Limiting · Auth │
└────────────────────────────────────────────────────┘
│
▼
┌─ APPLICATION LAYER ────────────────────────────────┐
│ Stateless app servers (horizontal scale) │
│ Microservices · Service Mesh │
│ Worker processes (background jobs) │
└────────────────────────────────────────────────────┘
│
┌───────────┼───────────┐
▼ ▼ ▼
┌─ CACHE ──┐ ┌─ MESSAGING ──┐ ┌─ DATA ─────────┐
│ Redis │ │ Kafka, SQS │ │ Postgres / MySQL│
│ Memcached│ │ RabbitMQ │ │ MongoDB │
│ CDN cache│ │ NATS │ │ Cassandra │
└──────────┘ └───────────────┘ │ Redis │
│ Elasticsearch │
│ S3 (object) │
└─────────────────┘
┌─ OBSERVABILITY ────────────────────────────────────┐
│ Logs (ELK, Loki) │
│ Metrics (Prometheus, Grafana) │
│ Traces (Jaeger, Honeycomb, OpenTelemetry) │
└────────────────────────────────────────────────────┘
System design = ghép các building block này theo requirement cụ thể.
5. Back-of-the-envelope math
Kỹ năng quan trọng: ước lượng nhanh capacity. Ví dụ Twitter:
- 500M user, 10% active hằng ngày → 50M DAU.
- Mỗi DAU đọc 100 tweet, post 1 tweet → 5B read, 50M write/ngày.
- 50M write / 86400s ≈ 580 write/s peak ~ 5×580 = 2900/s.
- Mỗi tweet 280 ký tự + metadata ~ 1KB → 50M × 1KB = 50GB/ngày, 18TB/năm.
- Read 5B / 86400 ≈ 58k QPS read peak ~ 290k QPS.
Số liệu này dẫn đến:
- Read-heavy 100×+ → cần cache mạnh + read replica.
- Write 3k/s → 1 Postgres node thừa sức (Postgres làm 50k+ write/s).
- 50GB/ngày → cần partitioning sau 1-2 năm.
- Geographic — DAU global → CDN + multi-region read replica.
5.1. Bảng số quan trọng nên thuộc lòng
| Operation | Latency |
|---|
| L1 cache | 1 ns |
| L2 cache | 4 ns |
| RAM access | 100 ns |
| SSD random read | 50–150 µs |
| HDD seek | 10 ms |
| Network LAN (cùng DC) | 0.5 ms |
| Network cross-DC (cùng region) | 1–5 ms |
| Network cross-region (US ↔ EU) | 50–100 ms |
| Network cross-globe (US ↔ APAC) | 100–300 ms |
6. CAP & PACELC — recap
Đã học ở Database (Ch9). Recap:
- CAP: khi network partition (P), chọn Consistency hoặc Availability.
- PACELC: ngay cả khi không partition, vẫn phải chọn giữa Latency và Consistency.
System design phải nói rõ chọn gì cho từng operation:
- Đăng ký user → CP (consistency).
- Show profile → AP với cache (eventual OK).
- Click stream analytics → AP (eventual OK, scale tối đa).
- Banking transfer → CP, sync replication.
7. Khung tư duy phỏng vấn
- Clarify requirements — functional (cần làm gì) + non-functional (scale, latency, reliability). Hỏi rất nhiều ở bước này.
- Capacity estimation — DAU, QPS read/write, storage/năm, bandwidth.
- System interface (API) — endpoint chính, request/response shape.
- Data model — schema cho top entity, ước lượng size.
- High-level architecture — vẽ box và arrow. Bắt đầu đơn giản (1 server + 1 DB), scale dần.
- Detailed design — sharding strategy, cache layer, queue, replication.
- Identify bottleneck — đâu là bottleneck đầu tiên khi load tăng 10×?
- Discuss trade-offs — mỗi quyết định có cost. Phải nói rõ.
Mẹo phỏng vấn
Đừng tránh "đơn giản". Bắt đầu bằng kiến trúc đơn giản nhất chạy được (1 app + 1 DB), rồi incremental scale theo từng bottleneck.
Senior phỏng vấn quan tâm bạn biết khi nào cần phức tạp hơn nhiều với "tôi biết Kafka".
8. Anti-patterns System Design
- Premature microservice — chia microservice khi team < 50 người. Distributed monolith còn tệ hơn monolith.
- Buzzword stack — "Kafka + Cassandra + Kubernetes + GraphQL" cho app 100 user.
- Cargo cult — dùng "vì FAANG dùng" mà không hiểu lý do. Twitter/Uber có scale không giống bạn.
- Optimization premature — tối ưu cho 1B user khi mới có 100. Code đơn giản trước.
- Single Point of Failure (SPOF) ẩn — 1 DB master, 1 nginx, 1 cache cluster. Khi chết, cả hệ chết.
- Bỏ qua observability — không có logs/metrics/traces → không debug được khi prod chết.
9. Lộ trình học đề xuất
- Tuần 1: Ch1+2. Capacity math + LB. Tự tính capacity cho 1 idea app (TODO scale, blog scale).
- Tuần 2: Ch3. Caching. Setup Redis + cache-aside cho 1 endpoint, đo latency before/after.
- Tuần 3: Ch4+5. Data scaling + queue. Setup local Kafka + producer/consumer.
- Tuần 4: Ch6+7. Microservice + edge. Đọc Stripe, Discord, Cloudflare engineering blog.
- Tuần 5: Ch8. Case studies. Mỗi ngày 1 case study mock interview.
Sẵn sàng chưa? Bắt đầu từ Chương 1 — Scalability Fundamentals.