Giao diện
Từ Building Blocks đến Blueprints — Bạn đã sẵn sàng chưa?
Phase 1 đã trang bị cho bạn bộ từ vựng kiến trúc — DNS, TCP/UDP, HTTP, Load Balancing, Caching, Database Scaling. Giống như một kiến trúc sư đã biết tên và đặc tính của từng vật liệu: bê tông, thép, kính, gỗ. Nhưng biết vật liệu chưa đủ để thiết kế toà nhà — bạn cần hiểu cách kết hợp chúng dưới ràng buộc thực tế: ngân sách, thời tiết, số tầng, mục đích sử dụng.
Case Studies chính là bước tiếp theo — nơi bạn sẽ thấy các architect thực tế kết hợp những building blocks này dưới ràng buộc quy mô hàng tỷ người dùng, yêu cầu uptime 99.99%, và ngân sách hạn chế.
🎯 Mục tiêu
🎯 Sau bài này bạn sẽ:
- Tổng kết toàn bộ building blocks đã học trong Phase 1
- Hiểu sự khác biệt giữa "biết building blocks" và "thiết kế hệ thống"
- Preview các Case Studies sắp tới và building blocks cần thiết cho mỗi case
- Tự đánh giá mức độ sẵn sàng cho Phase tiếp theo
🧱 Tổng kết Phase 1 — Bảng building blocks
Trước khi bước sang Case Studies, hãy kiểm tra lại toàn bộ "vật liệu" bạn đã thu thập trong Phase 1. Mỗi building block đi kèm một câu hỏi trade-off cốt lõi — đây chính là loại câu hỏi bạn sẽ phải trả lời liên tục trong Case Studies.
| Building Block | Bài học | Câu hỏi trade-off cốt lõi | Đã nắm? |
|---|---|---|---|
| OSI Model | OSI Mental Model | L4 vs L7 — throughput hay intelligence? | ☐ |
| TCP vs UDP | TCP vs UDP | Reliability vs latency — bao nhiêu là đủ? | ☐ |
| DNS | DNS Resolution | TTL cao vs thấp — performance vs failover speed? | ☐ |
| HTTP versions | HTTP Evolution | HTTP/2 vs HTTP/3 — compatibility vs performance? | ☐ |
| Load Balancing | Load Balancing | L4 vs L7 — raw speed vs smart routing? | ☐ |
| Caching | Caching | Cache consistency vs freshness — stale data chấp nhận được không? | ☐ |
| Database Scaling | Database Design | Replication vs sharding — read scaling vs write scaling? | ☐ |
Cách dùng bảng này
In bảng ra hoặc copy vào notes app. Tick vào cột "Đã nắm?" khi bạn tự tin giải thích được cả hai phía của mỗi trade-off — không chỉ biết chọn cái nào, mà biết tại sao không chọn cái kia.
🔄 Từ building blocks đến blueprints
Sự khác biệt giữa Phase 1 và Case Studies giống như sự khác biệt giữa học từ vựng và viết luận:
Phase 1 — Bạn đã hỏi:
"Caching là gì? Khi nào dùng Redis vs Memcached?"
"Load Balancer hoạt động thế nào? Round-robin khác gì Least Connections?"
"Replication và Sharding khác nhau ở điểm nào?"
Case Studies — Bạn sẽ hỏi:
"Thiết kế hệ thống News Feed cho 2 tỷ người dùng — cache ở đâu, TTL bao nhiêu, invalidation strategy nào?"
"Khi celebrity có 100M followers tweet, fanout strategy nào không giết chết hệ thống?"
"Driver location cần update mỗi 3 giây — dùng TCP hay UDP, push hay pull?"
The key shift: từ hiểu WHAT mỗi component làm → quyết định HOW kết hợp chúng dưới specific constraints. Không còn đúng/sai tuyệt đối — chỉ có trade-offs phù hợp hoặc không phù hợp với bối cảnh cụ thể.
🗺️ Preview các Case Studies — Mỗi case study dùng building blocks nào?
🐦 Design Twitter → Đọc ngay
| Khía cạnh | Chi tiết |
|---|---|
| Critical blocks | Caching (fanout), Database (sharding by user_id), LB (API routing) |
| Key challenge | Celebrity posts reaching 100M followers trong vài giây |
| Phase 1 concepts needed | Cache-aside pattern, write-through, consistent hashing |
Khi Elon Musk tweet, hệ thống phải đẩy nội dung đến 100M+ timelines mà không crash. Đây là bài toán kinh điển về fanout — và bạn sẽ dùng mọi thứ từ caching đến database sharding để giải quyết nó.
📺 Design YouTube → Đọc ngay
| Khía cạnh | Chi tiết |
|---|---|
| Critical blocks | CDN/Caching (video delivery), DNS (GeoDNS), Database (metadata) |
| Key challenge | 500 giờ video upload mỗi phút |
| Phase 1 concepts needed | TCP vs UDP cho streaming, HTTP/2 cho API, cache layering |
500 giờ video mỗi phút = ~30.000 giờ mỗi giờ cần encode, store, và deliver. Bạn sẽ thấy DNS, CDN, caching phối hợp thành một pipeline phân phối video toàn cầu.
🚗 Design Uber → Đọc ngay
| Khía cạnh | Chi tiết |
|---|---|
| Critical blocks | Database (geospatial indexing), LB (real-time matching), Caching (driver locations) |
| Key challenge | Real-time matching riders–drivers với sub-second latency |
| Phase 1 concepts needed | UDP cho location updates, L4 LB cho WebSocket connections |
Mỗi 3 giây, hàng triệu drivers gửi GPS coordinates. Hệ thống phải index, query, và match trong vài trăm milliseconds — khi bạn đang đứng dưới mưa chờ xe.
💬 Design WhatsApp → Đọc ngay
| Khía cạnh | Chi tiết |
|---|---|
| Critical blocks | TCP/WebSocket (persistent connections), Database (message store), DNS (connection routing) |
| Key challenge | Exactly-once delivery đến 2B+ devices với end-to-end encryption |
| Phase 1 concepts needed | TCP reliability, consistent hashing cho connection servers |
2 tỷ thiết bị, mỗi thiết bị giữ persistent connection. Một tin nhắn phải đến chính xác một lần — không mất, không trùng. Đây là nơi TCP reliability gặp distributed systems ở quy mô khổng lồ.
📊 Ma trận Building Blocks × Case Studies
Bảng dưới đây cho thấy mỗi Case Study nhấn mạnh building blocks nào. Ô ●●● = critical, ●● = important, ● = có dùng nhưng không phải trọng tâm.
| Building Block | 📺 YouTube | 🚗 Uber | ||
|---|---|---|---|---|
| OSI Model (L4/L7) | ●● | ●● | ●●● | ●●● |
| TCP vs UDP | ● | ●●● | ●●● | ●●● |
| DNS | ● | ●●● | ●● | ●● |
| HTTP versions | ●● | ●●● | ●● | ● |
| Load Balancing | ●●● | ●● | ●●● | ●● |
| Caching | ●●● | ●●● | ●●● | ●● |
| Database Scaling | ●●● | ●● | ●●● | ●●● |
Đọc ma trận thế nào?
Nếu bạn đặc biệt yếu ở một building block, hãy ưu tiên Case Study có nhiều ●●● ở hàng đó — bạn sẽ thấy block đó được ứng dụng thực tế và hiểu sâu hơn nhiều so với chỉ đọc lý thuyết.
✅ Self-Assessment — Bạn đã sẵn sàng cho Case Studies chưa?
✅ Checklist triển khai
🌐 Networking Foundation
- [ ] Tôi có thể giải thích DNS resolution path mà không cần nhìn tài liệu
- [ ] Tôi biết khi nào chọn TCP vs UDP và có thể justify quyết định
- [ ] Tôi hiểu sự khác biệt giữa HTTP/1.1, HTTP/2, HTTP/3 và khi nào dùng version nào
- [ ] Tôi biết OSI model áp dụng thế nào vào việc chọn L4 vs L7 LB
🏗️ Infrastructure
- [ ] Tôi có thể thiết kế LB topology cho hệ thống với 1M+ concurrent users
- [ ] Tôi biết khi nào dùng reverse proxy vs forward proxy
- [ ] Tôi hiểu consistent hashing và tại sao nó quan trọng cho distributed systems
💾 Data Layer
- [ ] Tôi có thể chọn caching strategy (cache-aside, write-through, etc.) cho một use case cụ thể
- [ ] Tôi biết khi nào dùng Redis vs Memcached và justify được
- [ ] Tôi hiểu replication vs sharding và biết khi nào dùng cái nào
- [ ] Tôi có thể giải thích CAP theorem bằng ví dụ thực tế
🔗 Tổng hợp
- [ ] Tôi có thể trace một request lifecycle từ browser đến database
- [ ] Tôi có thể identify bottlenecks trong một kiến trúc đơn giản
- [ ] Khi đọc một system design, tôi nhận ra được trade-offs mà architect đã chọn
Đánh giá kết quả
12/14 trở lên → Bạn sẵn sàng cho Case Studies. Hãy bắt đầu ngay! 🚀
8–11 → Gần sẵn sàng. Review lại các bài bạn chưa tự tin — đặc biệt xem lại bảng building blocks ở trên và click vào bài tương ứng.
Dưới 8 → Đừng vội. Dành thêm thời gian ôn Phase 1 trước khi tiến tiếp. Case Studies sẽ rất khó hiểu nếu nền tảng chưa vững.
🧪 Final Assessment
🧠 Quiz
Câu 1 — Notification System
Bạn đang thiết kế một hệ thống notification cho ứng dụng với 50M users. Khi có event mới, notification cần đến tất cả users online trong vòng 2 giây. Building blocks nào quan trọng nhất và tại sao?
- [ ] A. Chỉ cần Database mạnh — store notifications rồi client poll mỗi 2 giây
- [x] B. WebSocket (persistent TCP connections) + Load Balancing (L4 cho WebSocket) + Caching (user online status) — push-based cho real-time, LB để phân tải connections, cache để biết ai đang online
- [ ] C. HTTP/2 server push + DNS load balancing — server push đủ nhanh, DNS phân tải
- [ ] D. UDP broadcast + CDN caching — UDP nhanh nhất, CDN giảm tải
Giải thích: Đáp án B đúng vì:
- WebSocket/TCP: Cần persistent connection để push notification real-time (poll-based quá chậm cho yêu cầu 2 giây)
- L4 Load Balancing: WebSocket connections cần L4 LB vì L7 LB sẽ break persistent connections
- Caching: Cache danh sách users online để biết gửi notification đến connection servers nào
- UDP broadcast (D) không đáng tin cậy, HTTP/2 server push (C) bị giới hạn bởi browser connection limits, chỉ Database (A) sẽ tạo quá nhiều load khi 50M clients poll liên tục
Câu 2 — E-commerce Flash Sale
Hệ thống e-commerce sắp có flash sale — 1 triệu users cùng truy cập trong 10 giây đầu. Sản phẩm chỉ có 1.000 items. Bạn ưu tiên building blocks nào?
- [ ] A. Database Sharding — chia data ra nhiều shard để tăng write throughput
- [ ] B. DNS Round Robin — phân tải users ra nhiều server
- [x] C. Caching (product page) + Load Balancing (L7 với rate limiting) + Database (optimistic locking cho inventory) — cache trang sản phẩm để giảm DB load, LB rate limit để chống DDoS, DB locking để đảm bảo không oversell
- [ ] D. CDN + HTTP/3 — deliver static content nhanh nhất có thể
Giải thích: Đáp án C đúng vì flash sale có 3 vấn đề cần giải quyết đồng thời:
- 1M reads/s cho product page → Cache là bắt buộc (Redis hoặc CDN edge cache)
- Spike traffic protection → L7 LB với rate limiting chống bot và DDoS
- 1.000 items, không được bán quá → Database-level locking (optimistic locking hoặc distributed lock) đảm bảo inventory accuracy
- Sharding (A) không cần thiết khi chỉ có 1.000 items — bottleneck ở read không phải write
- DNS (B) quá chậm để phản ứng với spike — TTL thường > 30 giây
Câu 3 — Global Chat Application
Bạn thiết kế chat application phục vụ users ở cả Việt Nam và Mỹ. Latency giữa 2 quốc gia là ~200ms. Làm sao để message delivery dưới 500ms end-to-end?
- [ ] A. Đặt tất cả servers ở US, dùng HTTP/3 QUIC để giảm connection setup time
- [ ] B. Dùng UDP thay TCP để giảm overhead — chat message nhỏ, mất vài tin cũng không sao
- [x] C. Multi-region deployment + DNS GeoDNS routing + TCP persistent connections + Message relay giữa regions — users kết nối đến region gần nhất, messages relay qua backbone nội bộ giữa regions
- [ ] D. Single region + Global CDN cache — cache messages ở edge locations gần user
Giải thích: Đáp án C đúng vì:
- GeoDNS: Route VN users → Singapore/HK region, US users → US West region — giảm latency từ 200ms xuống ~30ms cho mỗi user đến server gần nhất
- TCP persistent connections: Chat cần reliable delivery — mất tin nhắn không chấp nhận được (loại B)
- Inter-region relay: Message từ VN user → SG server → internal backbone → US server → US user. Internal backbone nhanh hơn public internet
- Tổng latency: ~30ms (VN→SG) + ~150ms (SG→US backbone) + ~10ms (US server→US user) = ~190ms < 500ms ✅
- Single region (A) nghĩa là VN users luôn chịu 200ms+ latency. CDN cache (D) không phù hợp cho real-time messaging
🎯 Bước tiếp theo — Hành trình bắt đầu
Xin chúc mừng! 🎉 Bạn đã hoàn thành Phase 1 — nền tảng quan trọng nhất của System Design. Mọi kiến trúc sư giỏi đều bắt đầu từ việc hiểu sâu từng viên gạch trước khi xây toà nhà. Và bạn đã làm được điều đó.
Bây giờ là lúc đặt những viên gạch vào đúng vị trí. Trong Case Studies, bạn sẽ không chỉ đọc — bạn sẽ thiết kế, đánh đổi, và bảo vệ quyết định kiến trúc của mình. Đó là kỹ năng mà mọi system design interview đều kiểm tra, và mọi production system đều đòi hỏi. Let's build! 💪
Bắt đầu hành trình Case Studies:
- → 🐦 Bắt đầu Case Study: Design Twitter — Fanout, timeline, celebrity problem
- → 📺 Design YouTube — Video pipeline, CDN, adaptive streaming
- → 🚗 Design Uber — Geospatial, real-time matching
- → 💬 Design WhatsApp — Messaging at 2B scale
Điều hướng: