🏳️🌈 GAY 1: NHẬP MÔN & NHỮNG TƯ THẾ CƠ BẢN
Chào anh em!
Sau khi đã khởi động ở GAY 0 và hiểu được System Design là cái quái gì rồi, hôm nay chúng ta sẽ chính thức bước vào GAY 1.
Đây là phần nền tảng nhất, chứa những "tư thế" cơ bản nhưng cực kỳ lợi hại.
Ông nào đi phỏng vấn mà hổng mấy kiến thức này thì chỉ có liệm thôi.
Chúng ta sẽ cùng nhau bóc tách 3 chương đầu tiên của Alex Xu theo phong cách vai gãy nhé!!
💃 Less 1: Từ quán phở lề đường đến chuỗi nhượng quyền triệu đô
(Scale từ 0 đến triệu user)
Để hiểu về cách mở rộng hệ thống, anh em hãy tưởng tượng mình vừa bỏ việc IT về mở một quán bán PHO. Quán PHO của các ông có thể trải qua các giai đoạn sau.
Giai đoạn 1: Quán PHO cô đơn (Single Server Setup)
Lúc mới khai trương:
- Khách vắng tanh.
- Một mình ông vừa làm chủ, vừa đứng bếp, vừa bê PHO, kiêm luôn thu xèng.
Trong IT, cái này gọi là:
Single Server Architecture
Một con máy chủ gánh hết:
- Web Server
- Application Server
- Database
Chạy thì được đấy.
Nhưng lỡ ông ốm (server sập) là:
Quán đóng cửa. Khách nhịn ăn PHO và đi ăn cơm. Dù PHO bên ông có ngon, có mọng nước, có trắng cỡ nào thì cũng mất cmn khách ròiii. Ko ổn 😒.
Giai đoạn 2: Quán PHO đang phất (Tách biệt nhiệm vụ)
Khách bắt đầu đông hơn. Ông đuối quá nên thuê thêm một đứa:
- Chuyên đứng thái thịt, bê phở.
- Còn ông chỉ thu xèng thôi.
Trong hệ thống thực tế:
Sau khi tách web và DB ra riêng, lúc này:
- Web lo xử lý request.
- Database lo lưu dữ liệu.
Thằng nào việc nấy.
Lỡ Web Server quá tải thì dữ liệu vẫn còn nguyên bên Database. Bắt đầu biết tư duy rồi đấy 🧠. Cái đáng khen ở đây là ông đã biết tách biệt nhiệm vụ, đảm bảo ko chết cả đôi, đây là tiền đề để scale lên chuỗi cửa hàng PHO ngon ngọt nước nhất VN đó.
Giai đoạn 3: Quán PHO tranding (Bắt buộc phải mở rộng)
Khách tiếp tục đông lên. Quán bắt đầu quá tải, hết bàn, khách bắt đầu phải đợi, khách ko ăn được, ko vui, mất khách.
Lúc này, ông có hai lựa chọn.
🔥 Vertical Scaling (Scale Up)
Ông tăng hiệu suất của tiệm bằng cách mua:
- Nồi nước lèo to gấp 5 lần.
- Thuê lực sĩ bưng một lúc 10 tô.
Trong hệ thống:
| Thành phần | Hành động |
|---|---|
| CPU | Tăng số lượng CPU/vCPU |
| RAM | Nâng cấp dung lượng RAM |
| SSD | Tăng dung lượng hoặc tốc độ ổ cứng |
Với cách này thì đơn giản thôi, chỉ vài click là xong. Dễ triển khai, chẳng thay đổi gì về kiến trúc hệ thống. Nhưng đổi lại chi phí sẽ cao hơn nhiều và server gặp sự cố, toàn bộ dịch vụ có thể bị ảnh hưởng. Và đến một lúc nào đó, sẽ không còn con server nào mạnh hơn để ông mua nữa. Hoặc tiền thuê đắt tới mức cắt cổ luôn, phải bán cả tiệm đi. Vì vậy mới sinh ra thêm 1 cách mở rộng khác nữa là Horizontal Scaling.
🚀 Horizontal Scaling (Scale Out)
Ông không mua nồi to nữa.
Ông tăng số lượng lên:
- 3 nồi nhỏ
- 3 nhân viên mới
Trong hệ thống:
| Thành phần | Hành động |
|---|---|
| Server | Thêm nhiều server mới |
| Database | Có thể cần Replication hoặc Sharding |
| Load Balancer | Phân phối request giữa các server |
Với cách này thì mở rộng gần như vô hạn luôn, cứ nhân bản nó lên là được. Chi phí sẽ tối ưu hơn khi ông mở rộng, thay vì một con server mạnh thì ta chơi 100 con server rách. Miễn là đáp ứng được nhu cầu hệ thống và tối ưu chi phí. Tuy nhiên kiến trúc chắc chắn sẽ phức tạp hơn, ông phải đồng bộ dữ liệu nè, điều hướng lưu lượng truy cập của người dùng giữa các server hợp lý nè, vận hành và giám sát 100 con chắc chắn nhọc hơn 1 con nữa nè...
🎯 Kết luận
Nếu muốn phục vụ:
- 1 triệu user
- 10 triệu user
- 100 triệu user
Thì:
Horizontal Scaling gần như là con đường bắt buộc.
Giai đoạn 4: Quán PHO ngọt nước với 100 nhân viên (Thế giờ đến lượt ai phục vụ)
Khi quán có:
- Hàng nghìn khách kéo tới, nếu ko có người điều phối và chỉ định rõ, chắc chắn sẽ có đứa làm tới kiệt sức, có đứa lại ngồi lướt top top
Ông cần một người đứng trước cửa đón khách và điều phối nhân viên phục vụ. Với tiêu chí là cao bằng, ai cũng phải làm, miễn ko phải ông là được. Và trong IT người điều phối này gọi là Load Balancer.
Trong IT thì kiểu như:
Khách 1 → Server 1
Khách 2 → Server 2
Khách 3 → Server 3
Khách 4 → Server 4
Chia tải đều cho tất cả server. Để không server nào bị rảnh và cũng ko cái nào bị quá tải. Đây chính là chức năng của Load Balancer, nó sẽ điều phối các user tới server sao cho balance nhất.
Giai đoạn 5: Quán PHO lâu năm nhiều kinh nghiệm
Là 1 ông chủ có đầu óc, bạn thường xem xét hành vi của khách hàng để cải thiện chất lượng dịch vụ. Nếu khách liên tục gọi:
"Cho em một tô PHO tái nạm."
Nếu mỗi lần gọi mới:
- Thái thịt
- Cắt hành
- Chuẩn bị topping
thì rất chậm.
Là 1 ông chủ có đầu óc, ông cảm thấy PHO của ông còn có thể ra nhanh hơn. Nếu chuẩn bị sẵn:
- 50 phần thịt
- Hành lá
- Rau thơm
Để khách gọi là có ngay.
Đó chính là:
Cache
Cache là gì?
Những dữ liệu:
- Truy cập nhiều
- Ít thay đổi
sẽ được lưu sẵn trong:
- Redis
- Memcached
để không phải xuống Database liên tục. Cực nhanh cực tiện. Giảm tải áp lực cho DB. Xời quá ngonn.
CDN là gì?
Giả sử quán phở Hà Nội nổi tiếng.
Khách ở Sài Gòn muốn ăn.
Chẳng lẽ ngày nào cũng ship từ Hà Nội vào?
Ông mở:
Một chi nhánh tại Sài Gòn.
Có sẵn:
- Nước lèo
- Gia vị
- Topping
ở đó.
Khách ở Sài Gòn chỉ cần chạy ra đầu ngõ là có thể húp được ngay bát PHO nóng hổi thơm ngon. Xời quá ngonn.
Trong IT:
CDN (Content Delivery Network)
là hệ thống đặt dữ liệu ở nhiều nơi trên thế giới để phục vụ user từ vị trí gần nhất.
Thường dùng cho dữ liệu tĩnh:
- Hình ảnh
- Video
- CSS
- JavaScript
Ngoài ra còn 1 số skill mà ông chủ sẽ áp dụng để tăng tính sẵn sàng và phòng ngừa rủi ro cho quán phở nữa như là Database Replication, Stateless Web Tier, Data Centers, Message Queue, Logging, Metrics, Automation. Nhưng tạm thời chúng ta chỉ nói đến Cache và CDN để anh không ngợp nhé.
💃 Less 2: Tính toán vo
Back-of-the-envelope Estimation
Nhiều anh em đi phỏng vấn System Design bị khựng ở phần này.
Người ta vừa đưa đề bài. Chưa gì đã lao vào vẽ. Ờ thì cũng ra được cái sơ đồ đấy, chắc cũng ra được cái hệ thống đấy nhưng đến lúc bị hỏi:
"Một ngày hệ thống lưu bao nhiêu dữ liệu?"
hoặc
"Cần bao nhiêu GB ổ cứng?"
thì đứng hình.
Alex Xu dạy một kỹ năng cực quan trọng:
Back-of-the-envelope Estimation
Tạm dịch:
Tính toán vo trên giấy.
Mục đích:
- Ước lượng quy mô hệ thống. Nhưng dù chỉ là ước lượng thôi cũng phải có nghệ thuật, không thể chỉ dựa trên kinh nghiệm được, hãy sử dụng những con số cụ thể để chứng minh ước lượng là đúng.
- Biết mình đang thiết kế gì cho bao nhiêu người dùng.
Những con số cần thuộc lòng
| Giá trị | Kích thước |
|---|---|
| 2¹⁰ | 1 KB |
| 2²⁰ | 1 MB |
| 2³⁰ | 1 GB |
| 2⁴⁰ | 1 TB |
| 2⁵⁰ | 1 PB |
Ngoài ra:
1 ngày = 86.400 giây
≈ 100.000 giây
để dễ nhẩm.
Ví dụ thực chiến
Thiết kế Twitter phiên bản "cỏ"
Giả sử:
- 100 triệu DAU
- Mỗi user đăng 1 tweet/ngày
- Mỗi tweet = 100 Bytes
Tính toán
1 ngày:
100.000.000 user × 1 tweet × 100 bytes = 10.000.000.000 bytes ≈ 10 GB
1 năm:
10 GB × 365 ≈ 3.65 TB
Đi phỏng vấn mà trả lời được:
"Hệ thống này mỗi năm cần khoảng 4TB lưu trữ cho dữ liệu tweet."
Nghe rất ra dáng một ông kỹ sư đã quen làm việc với số liệu phết ấy chứ. Nếu mà người ta hỏi vặn thì cho họ xem cách ta tính, xời cứ phải gọi là trong lòng bàn tay.
💃 Less 3: Quy trình 4 bước cân mọi kèo phỏng vấn
Tôi để ý thấy nhiều ông code rất giỏi, làm nhiều hệ thống, 3-4 năm nghề mà khi phỏng vấn System Design lại tạch. Choán quá choán.
Có lẽ 1 phần là do:
Thấy đề bài là nhảy vào giải pháp ngay, vẽ tùm lum. Điều này không phải hiếm, hãy coi cuộc phỏng vấn như 1 buổi làm việc bình thường chứ không phải cuộc thi, đừng gấp. Hãy cho họ thấy kỹ năng giao tiếp, cách mổ sẻ vấn đề của 1 senior và sự điềm tĩnh của 1 CEO.
Theo kinh nghiệm Xu Alex, ông ấy đưa ra một Framework cực kỳ nổi tiếng.
1. Understand & Scope
↓
2. High-Level Design
↓
3. Design Deep Dive
↓
4. Wrap Up
Bước 1: Hỏi để thu hẹp phạm vi
(3 - 5 phút)
Đừng vẽ ngay. Hãy hỏi.
Ví dụ:
- Có bao nhiêu user?
- Bao nhiêu DAU?
- Có cần video không?
- Tập trung vào tính năng nào?
Mục tiêu:
Thu hẹp phạm vi bài toán.
Bước 2: Vẽ thiết kế tổng quan
(10 - 15 phút)
Bắt đầu vẽ:
Nếu có thể hãy vừa vẽ vừa nói về những gì mình đang nghĩ, đưa người phỏng vấn theo lối suy nghĩ của chúng ta. Đừng im lặng, đừng để họ đoán ta đang nghĩ gì, họ ko phải tiên tri, pls. Rất nhiều anh em gặp phải vấn đề này.
Hãy hỏi:
"Kiến trúc tổng quan này có hợp lý không anh?"
Kéo người phỏng vấn tham gia vào cuộc thảo luận. Hãy coi họ là khách hàng, thảo luận với họ để vẽ ra được sơ đồ khiến họ ưng ý nhất 
, nó cũng giúp anh em show ra kỹ năng giao tiếp và làm việc nhóm. Họ sẽ đánh giá rất cao đó nha.
Bước 3: Đào sâu chi tiết
(15 - 20 phút)
Đến lúc này anh em đã có 1 sơ đồ tổng quát đúng theo yêu cầu của người phỏng vấn, hãy hỏi họ xem muốn đào sâu phần nào, chức năng nào, chúng ta sẽ tập trung vào đó. Hãy vẽ chi tiết về phần đó, cách các thành phần trong hệ thống giao tiếp với nhau, hãy khoanh vào những phần mà bạn thấy là quan trọng nhất.
Thường người phỏng vấn sẽ hỏi một số câu đơn giản như:
- Nếu node này sập thì sao?
- Nếu traffic tăng gấp 100 lần thì sao?
- Làm sao giảm latency xuống dưới 100ms?
Lúc này thì anh em cứ thế mà bung xoã kiến thức và kinh nghiệm mà mình có thôi. Nhưng chủ yếu vẫn là thảo luận về các vấn đề hiệu năng, độ sẵn sàng, tính nhất quán của dữ liệu và các điểm sập duy nhất.
Ví dụ:
App Chat
Tập trung:
- WebSocket
- Heartbeat
- Connection Management
YouTube
Tập trung:
- Video Upload
- Video Encoding
- CDN Distribution
Bước 4: Chốt hạ
(3 - 5 phút)
Đừng kết thúc bằng:
"Em vẽ xong rồi."
Bạn phải chủ động nhận xét về hệ thống mình vừa vẽ ra:
- Hệ thống đang mạnh ở đâu.
- Điểm yếu ở đâu.
- Tương lai cần cải thiện gì.
Ở bước này ông nào mà out trình vẽ luôn thêm các phương án khác nữa thì cứ phải gọi là hết nước chấm.
Ví dụ:
Hiện tại hệ thống phục vụ tốt 10 triệu user. Tuy nhiên nếu lên 100 triệu user thì Database Master sẽ trở thành bottleneck. Khi đó em sẽ cân nhắc Sharding hoặc chuyển sang một giải pháp NoSQL phù hợp hơn.
Người phỏng vấn rất thích ứng viên:
Hiểu rõ giới hạn của chính thiết kế mình.
📚 Góc từ điển – Thuật ngữ & Từ viết tắt
| Từ viết tắt | Ý nghĩa |
|---|---|
| DAU | Daily Active Users |
| CPU | Central Processing Unit |
| RAM | Random Access Memory |
| DB | Database |
| CDN | Content Delivery Network |
| LB | Load Balancer |
| Cache | Bộ nhớ đệm |
| SSD | Solid State Drive |
| KB | Kilobyte |
| MB | Megabyte |
| GB | Gigabyte |
| TB | Terabyte |
| PB | Petabyte |
| Scope | Phạm vi bài toán |
| Bottleneck | Điểm nghẽn hệ thống |
🍻 Lời kết cho Gay 1
Anh em thấy đấy.
Ba chương đầu của Alex Xu thực chất chỉ xoay quanh ba thứ:
✅ Hiểu cách mở rộng hệ thống
✅ Biết cách ước lượng quy mô
✅ Có quy trình tiếp cận bài toán rõ ràng
Nắm chắc ba cái cọc tiêu này.
Những phần sau sẽ dễ thở hơn rất nhiều.
🚀 GAY kế nói gì :> ???
PHẦN 2: NHỮNG KẺ GÁC CỔNG CỦA HỆ THỐNG
Chúng ta sẽ gặp:
- Rate Limiter
- Consistent Hashing
- Distributed Systems cơ bản
Những thứ xuất hiện gần như trong mọi cuộc phỏng vấn System Design hiện đại.
Giờ thì làm một ngụm bia thôi anh em! 🍻
All rights reserved
