LỜI GIÁO SƯ: “Đừng bao giờ thiết kế một hệ thống khổng lồ cho 1 triệu người dùng khi anh mới chỉ có 10 người dùng. Kiến trúc hệ thống là sự tiến hóa, không phải là phép màu một bước lên mây.”
Ví dụ thực tế: Anh mở một quán Phở. Hãy xem quán Phở của anh tiến hóa thế nào.
Mô hình tổng thể
[Single Server] → [Web + Database] → [Load Balancer]
→ [Cache/Replication] → [Stateless + CDN + Queue]
BƯỚC 1: QUÁN PHỞ VỈA HÈ (Single Server)
Mọi thứ (Web, API, Database) đều nằm trên 1 máy chủ duy nhất. Giống như anh vừa làm đầu bếp, vừa bưng bê, vừa thu ngân.
[ Khách hàng ]
│
▼ (Yêu cầu)
┌───────────────────────┐
│ SERVER DUY NHẤT │
│ ├─ Giao diện (Web) │
│ ├─ Nấu ăn (Logic/API) │
│ └─ Sổ sách (Database) │
└───────────────────────┘
Ưu điểm: Rẻ, dễ làm, dễ deploy. Tử huyệt: Server sập (đầu bếp ốm) ──► Quán đóng cửa (Hệ thống chết toàn tập).
BƯỚC 2: TÁCH BẾP VÀ SỔ SÁCH (Tách Web và Database)
Khách đông lên, máy chủ quá tải RAM. Anh phải mua thêm 1 máy chuyên làm Database.
[ Khách hàng ]
│
▼
┌───────────────┐ ┌────────────────┐
│ WEB SERVER │ ◄────► │ DATABASE SERVER│
│ (Xử lý Logic) │ │ (Lưu trữ) │
└───────────────┘ └────────────────┘
Lợi ích: Hai máy chạy độc lập. Máy Web cần CPU mạnh để tính toán, máy Database cần Ổ cứng/RAM lớn để lưu dữ liệu. Tối ưu chi phí phần cứng.
BƯỚC 3: MƯỚN THÊM NHÂN VIÊN VÀ QUẢN LÝ (Load Balancer & Scale Out)
Khách xếp hàng dài. 1 Web Server không chịu nổi. Anh mướn thêm 3 nhân viên (Web Server) và 1 người Quản lý (Load Balancer) để chia việc.
[ Khách hàng ]
│
▼
┌───────────────────┐
│ LOAD BALANCER │ ──► (Quản lý: Chia đều khách cho nhân viên rảnh)
└─────────┬─────────┘
┌──────────────┼──────────────┐
▼ ▼ ▼
┌─────────┐ ┌─────────┐ ┌─────────┐
│ WEB 1 │ │ WEB 2 │ │ WEB 3 │ ──► (Scale Out / Mở rộng ngang)
└────┬────┘ └────┬────┘ └────┬────┘
│ │ │
└──────────────┼──────────────┘
▼
┌────────────────┐
│ DATABASE TỔNG │
└────────────────┘
BƯỚC 4: GIẢM TẢI CHO NHÀ KHO VÀ ĐẦU BẾP (Cache & Database Replication)
Vấn đề: 3 nhân viên cùng giành nhau ghi/đọc sổ sách (Database) khiến Database bị “thắt cổ chai” (Bottleneck). Giải pháp:
- Cache (Tủ kính giữ nhiệt): Những món gọi nhiều (Menu, món hot) đưa ra tủ kính ngoài, không cần vào bếp nấu lại.
- Replication (Tách sổ đọc/ghi): Master DB chỉ dùng để ghi tiền vào. Slave DB chỉ dùng để đọc thông tin.
[ Khách hàng ] ──► [ Load Balancer ] ──► [ Web Servers ]
│
┌─────────────────────────────────────────┤
│ │
▼ ▼
┌───────────────┐ ┌───────────────┐
│ REDIS CACHE │ │ MASTER DB │ ◄── (Chỉ Ghi dữ liệu)
│ (Lưu Menu hot,│ └───────┬───────┘
│ đọc siêu tốc)│ │ (Đồng bộ)
└───────────────┘ ▼
┌───────────────┐
│ SLAVE DB(s) │ ◄── (Chỉ Đọc dữ liệu)
└───────────────┘
BƯỚC 5: MỞ CHUỖI XUYÊN QUỐC GIA (Stateless & CDN)
Hệ thống của anh giờ có người dùng ở Mỹ, Nhật, VN.
- CDN (Mạng phân phối nội dung): Để khách ở Mỹ không phải chờ tải ảnh từ server VN, anh thuê các kho chứa ảnh (CDN) ở Mỹ.
- Stateless Web Tier (Phi trạng thái): Khách hàng đang nới chuyện với Web 1, lỡ Web 1 chết, họ bị đá văng ra (mất session). Giải pháp là mang “Trí nhớ” của Web 1 cất vào một chỗ dùng chung (Session Store). Mọi Web Server đều ngu như nhau, nhưng lấy “Trí nhớ” từ kho chung.
[ Khách VN ] [ Khách Mỹ ]
│ │
▼ (Tải ảnh từ kho VN) ▼ (Tải ảnh từ kho Mỹ)
┌─────────┐ ┌─────────┐
│ CDN VN │ │ CDN MỸ │
└─────────┘ └─────────┘
│ │ (Gọi API Logic)
└──────────────────┬──────────────────┘
▼
[ Load Balancer ]
│
┌─────────────┴─────────────┐
▼ ▼
[ WEB 1 ] [ WEB 2 ] ──► (Stateless: Không nhớ ai cả)
│ │
└─────────────┬─────────────┘
▼
[ SESSION STORE (Redis) ] ──► (Lưu trạng thái đăng nhập chung)
Kết luận
Tiến trình anh bắt buộc phải nhớ khi scale một hệ thống:
- Giai đoạn 1:
1 Server(Chỉ để chạy thử nghiệm, ra mắt MVP). - Giai đoạn 2:
Web Server + Database(Bắt đầu có traffic). - Giai đoạn 3:
Load Balancer + Nhiều Web Server(Tăng cường sức mạnh xử lý). - Giai đoạn 4:
Cache + DB Master/Slave(Chống sập Database). - Giai đoạn 5:
Stateless + CDN + Message Queue(Tối ưu trải nghiệm toàn cầu, hàng triệu User).
Nắm vững bức tranh này, anh sẽ hiểu vì sao phải học Rate Limiter (Chương 4), Consistent Hashing (Chương 5) hay Key-Value Store (Chương 6) ─ vì chúng chính là “vật liệu” để xây dựng nên các cỗ máy ở Giai đoạn 4 và 5.
Tóm tắt bỏ túi (Take away)
Mở rộng hệ thống theo nhu cầu thực tế: đo tải, tìm nút thắt, rồi thêm đúng thành phần cần thiết. Không mặc định rằng kiến trúc lớn hơn luôn tốt hơn.