---
title: "Thiết kế hệ thống - ước lượng tải, load balancer, cache, queue, replication và partitioning"
description: "Khóa học nền tảng về thiết kế hệ thống, giúp bạn đi từ requirement, tải cao điểm và constraint tới kiến trúc hoàn chỉnh. Bạn học cách ước lượng tài nguyên, chọn đúng load balancer, cache, queue hay replica theo triệu chứng đo được, tìm bottleneck và so sánh phương án bằng số liệu thay vì cảm tính."
canonical: "https://200lab.io/courses/thiet-ke-he-thong-uoc-luong-tai-load-balancer-cache-queue-replication-va-partitioning"
type: "course"
course_type: "course"
learning_type: "free_form"
published: "2026-10-04T01:23:05Z"
students: 85
---

## Khóa học này mang lại gì cho bạn

Khi một app bắt đầu có người dùng thật, bạn sẽ sớm phải đối mặt với câu hỏi: hệ thống cần thêm những thành phần nào và đưa vào ở thời điểm nào. Khóa học này hướng dẫn bạn đi từ requirement, tải cao điểm và constraint để dựng kiến trúc, tìm điểm nghẽn và đưa ra quyết định kỹ thuật có cơ sở.

- **Chuyển hóa** requirement nghiệp vụ thành các chỉ số kỹ thuật kiểm tra được, từ SLO, error budget cho đến RPO và RTO.
- **Ước lượng** nhanh dung lượng lưu trữ, băng thông mạng và số instance cần chạy dựa trên Little’s Law và tải cao điểm theo từng phút.
- **Xác định** đúng source of truth cho từng loại dữ liệu để các tầng dữ liệu dẫn xuất như cache hay search index luôn dựng lại được.
- **Lựa chọn** các thành phần cơ bản gồm load balancer, cache, queue, read replica, table partitioning, object storage và CDN dựa trên triệu chứng kỹ thuật thực tế.
- **Truy tìm** bottleneck đầu tiên trên request path bằng phương pháp USE trước khi quyết định mở rộng phần cứng.
- **So sánh** các phương án thiết kế cạnh nhau bằng số liệu đo lường cụ thể và lập tài liệu ADR lưu vết lại quyết định kiến trúc.

Khóa học trang bị tư duy thiết kế nền tảng độc lập với framework, công nghệ hay nhà cung cấp cloud, giúp bạn tự tin đưa ra giải pháp vừa vặn cho workload của mình.

## Khóa học cung cấp những nền tảng nào

Khóa học lấy việc lượng hóa đầu vào thiết kế làm kim chỉ nam xuyên suốt: mọi lựa chọn kiến trúc đều phải bắt đầu từ requirement, constraint và workload đo đếm được. Kiến thức về mô tả tải và đánh giá hiệu năng bám sát các nguyên lý trong [Designing Data-Intensive Applications](https://dataintensive.net/) của Martin Kleppmann, cách vận hành độ tin cậy dựa trên tài liệu [Service Level Objectives](https://sre.google/sre-book/service-level-objectives/) của Google SRE, cùng kỹ thuật điều tra điểm nghẽn qua [phương pháp USE](https://www.brendangregg.com/usemethod.html) của Brendan Gregg.

### 1. Request đi qua những đâu, state nằm ở đâu và đọc dashboard thế nào

Bạn bắt đầu từ việc chuẩn hóa sơ đồ request path từ client tới database, đánh dấu rõ những mắt xích đang nắm giữ state. Bài học phân định ranh giới giữa tầng stateless và stateful, hướng dẫn đưa session ra khỏi bộ nhớ process để app scale ngang an toàn mà không làm người dùng bị đăng xuất. Ở phần quan sát, bạn học cách đọc latency qua các mốc percentile p50, p95, p99 thay vì số trung bình dễ gây ngộ nhận, đồng thời đối chiếu throughput với latency. Cuối chặng, bạn phân biệt rõ giữa utilization và saturation để phát hiện hàng chờ connection pool đang tắc nghẽn ngay cả khi CPU vẫn ở mức thấp.

### 2. Các loại requirement và cách biến chúng thành số liệu

Từ bài toán tính năng xuất hóa đơn qua hết test chức năng nhưng bị load balancer cắt kết nối trong đêm cao điểm, bạn phân biệt rõ functional requirement, non-functional requirement và constraint. Bạn thực hành tám nhóm câu hỏi chất lượng dịch vụ cần làm rõ với product trước khi bắt tay vẽ sơ đồ kiến trúc. Với các dịch vụ quan trọng, bạn chuyển hóa những yêu cầu định tính như nhanh và ổn định thành hai dòng SLO cụ thể, từ đó tính ra error budget trong cửa sổ 30 ngày và quy đổi thành số phút gián đoạn ở tải trung bình và giờ cao điểm. Phần cuối giúp bạn định lượng mức chấp nhận mất mát dữ liệu và thời gian gián đoạn qua RPO, RTO khi giải quyết mâu thuẫn giữa chi phí và độ sẵn sàng.

### 3. Mô tả workload, ước lượng nhanh và xác định dữ liệu gốc

Bạn học cách bóc tách workload từ access log theo từng phút, xác định tải cao điểm, độ dài đợt burst, tỉ lệ đọc ghi và kích thước payload thay vì nhìn vào số trung bình ngày phẳng lặng. Với bài toán tính năng chat mới, bạn áp dụng kỹ thuật ước lượng nhanh trên giấy để tính ra dung lượng đĩa mỗi năm, băng thông card mạng và lưu lượng ra internet. Bạn áp dụng Little’s Law để quy đổi số request mỗi giây và thời gian xử lý thành số request đồng thời, từ đó xác định số instance cần chạy kèm phần headroom dự phòng an toàn. Bài cuối chặng giúp bạn phân định source of truth và derived data, loại bỏ rủi ro ghi đồng thời vào hai nơi và thiết lập quy trình dựng lại dữ liệu dẫn xuất khi có sự cố.

### 4. Các thành phần cơ bản: khi nào cần và tradeoff

Chặng này khảo sát sáu nhóm thành phần hạ tầng cốt lõi qua câu hỏi: điều kiện nào bắt buộc phải dùng, gánh bớt được bao nhiêu tải và tradeoff đi kèm là gì. Bạn tính toán số instance dự phòng N+1 phía sau load balancer, phân biệt ranh giới giữa load balancer, reverse proxy và API gateway. Với mô hình cache-aside trên Redis, bạn đo lường lượng truy vấn đọc giảm tải cho database qua hit ratio và chấp nhận khoảng trễ dữ liệu theo TTL. Tiếp đó, bạn dùng queue để đưa tác vụ gửi email ra ngoài request path, dùng read replica gánh bớt tải đọc cho primary, chia partition theo ngày để thay thế lệnh xóa dữ liệu cũ nặng nề, và tách file nhị phân sang object storage cùng CDN để giảm tải băng thông lẫn thời gian backup database.

### 5. Hệ thống lớn lên theo từng nấc

Bạn quan sát một hệ thống thương mại trực tuyến phát triển qua năm nấc tải trên cùng một sơ đồ kiến trúc, từ cấu hình tối giản một app một database cho tới cụm hạ tầng bảy thành phần. Mỗi nấc nâng cấp đều xuất phát từ một triệu chứng kỹ thuật đo đếm được trên dashboard, giúp bạn nhận diện thành phần nào đã đến lúc phải bổ sung và thành phần nào tuyệt đối chưa cần đưa vào để tránh lãng phí chi phí. Chặng học khép lại bằng bài toán thiết kế dịch vụ rút gọn link từ requirement sơ khởi tới kiến trúc hoàn chỉnh chịu tải lệch tâm. Bạn cân nhắc giữa hai giải pháp sinh mã ngắn bằng sequence base62 hoặc hash cắt ngắn kèm cơ chế thử lại khi trùng mã.

### 6. Tìm bottleneck và xem lỗi lan ra như thế nào

Trước khi vội vã nâng cấp phần cứng, bạn lập bảng kiểm tra utilization, saturation và errors cho từng mắt xích trên request path để chỉ ra đúng tài nguyên đang chạm trần năng lực. Bạn nhận diện hiện tượng lỗi dây chuyền khi một service phụ phản hồi chậm làm cạn kiệt thread pool dùng chung của app, khiến các endpoint kinh doanh trọng yếu bị dừng đột ngột. Chặng học cung cấp công thức toán học tính toán availability cho chuỗi dependency nối tiếp và hệ thống có thành phần dự phòng song song. Bài toán tình huống phân tích sự cố câu lệnh báo cáo quét bảng hàng trăm triệu dòng gây nghẽn đĩa Postgres primary, từ đó tách sang replica báo cáo riêng biệt kết hợp chia partition theo tháng.

### 7. Thiết lập, so sánh phương án và ghi lại quyết định thiết kế

Đối mặt với bài toán tìm kiếm chấp nhận lỗi chính tả, bạn thiết lập hai phương án thiết kế độc lập từ cùng một bộ requirement: tận dụng index trigram trong Postgres hoặc dựng cụm Elasticsearch nhận dữ liệu đồng bộ qua worker. Bạn đưa hai phương án vào bảng so sánh dựa trên các tiêu chí kỹ thuật đo được gồm p99 latency, chi phí vận hành, độ phức tạp hạ tầng, failure mode và độ trễ dữ liệu thay vì liệt kê ưu nhược điểm chung chung. Mọi phân tích được đúc kết thành tài liệu ADR với bối cảnh số liệu rõ ràng và điều kiện xem lại quyết định trong tương lai. Bài tình huống tổng hợp cuối khóa yêu cầu bạn thiết kế lại hệ thống khi sự kiện flash sale đẩy tải lên gấp 40 lần, đánh giá tradeoff giữa mở rộng replica và dùng cache kết hợp queue qua kịch bản load test k6.

## Vì sao 200Lab tạo ra khóa học này

Ngày nay, việc thêm một công nghệ mới vào hạ tầng đã trở nên thuận tiện hơn trước rất nhiều. Các dịch vụ managed service hay công cụ tạo code tự động có thể dựng lên một kiến trúc phân tán gồm đầy đủ cache, queue và replica chỉ sau vài câu lệnh. Sự tiện lợi đó khiến ranh giới sai lầm chuyển dịch về phía người kỹ sư: bạn phải tự trả lời xem hệ thống của mình có thực sự cần thành phần đó hay không, và đưa vào ở thời điểm nào là hợp lý.

Khi thiếu số liệu kỹ thuật làm điểm tựa, các đội ngũ thường rơi vào hai thái cực đối lập. Dựng thừa thành phần khiến bạn phải gánh vác việc vận hành những hệ thống vượt quá năng lực kiểm soát của nhân sự, dẫn đến sự cố kéo dài nhiều giờ ngoài giờ trực và chi phí server vượt ngân sách cho phép. Dựng thiếu thành phần khiến hệ thống chạy êm ả lúc ngày thường nhưng lập tức nghẽn cứng ở tầng database ngay trong những phút cao điểm bán hàng, làm rơi rụng đơn hàng của khách.

200Lab tạo ra khóa học này nhằm giúp bạn thay thế thói quen phán đoán cảm tính bằng các phép tính kỹ thuật có đơn vị rõ ràng. Bạn sẽ biết cách tính số lượng instance theo Little’s Law, xác định hit ratio tối thiểu để database giữ được headroom an toàn, và quy đổi cam kết SLO thành số phút gián đoạn cho phép. Những công thức ước lượng này là công cụ giúp bạn bảo vệ phương án trước đội ngũ và chuẩn bị năng lực chịu tải cho hệ thống trước các đợt tăng trưởng lớn.

Mục tiêu của 200Lab là biến bạn thành nhân vật trung tâm trong mọi cuộc thảo luận kỹ thuật. Mỗi khi tiếp nhận một yêu cầu kinh doanh mới, bạn có thể tự tin phản hồi bằng số liệu tải tính toán, gắn từng thành phần kiến trúc với một triệu chứng vận hành có thật, và để lại tài liệu quyết định chuẩn mực cho những đồng nghiệp kế thừa hệ thống sau này.

## Những vấn đề thường gặp khi thiết kế hệ thống

Nhiều sự cố hệ thống bắt nguồn từ việc đưa ra quyết định kiến trúc trước khi có số liệu đo đạc cụ thể:

- Tăng gấp đôi số instance nhưng throughput không đổi và p99 tăng vọt — CPU của Postgres primary đã chạm ngưỡng bão hòa nên việc thêm instance app chỉ dồn thêm hàng chờ truy vấn vào database.
- Dashboard báo trung bình 40 request/giây nhưng server liên tục trả lỗi 502 vào giờ cao điểm — Số trung bình theo ngày che giấu đợt burst tải lên tới 900 request/giây dồn vào ba phút sau thông báo push notification.
- Lấy kết quả benchmark 2.000 request/giây của endpoint health check để ước lượng cho API nghiệp vụ — Request kiểm tra sức khỏe chỉ tốn 5 ms trên bộ nhớ và framework, trong khi API thực tế tốn 80 ms vì phải đọc ghi qua database.
- Bật thêm nhiều instance app khiến người dùng liên tục bị văng đăng nhập — Thông tin phiên làm việc đang lưu trong bộ nhớ RAM nội bộ của instance thay vì đưa về một session store tập trung bên ngoài.
- Endpoint checkout bị treo mã lỗi 504 trong khi CPU của server app chỉ dùng 15% — Service gợi ý phụ phản hồi chậm khiến toàn bộ thread pool của app bị chiếm dụng để chờ đợi qua network.
- p99 của API giao dịch tăng vọt vào đúng một khung giờ cố định mỗi sáng — Câu lệnh quét báo cáo doanh thu chạy trên cùng database primary và tranh chấp toàn bộ băng thông đọc của ổ đĩa.
- Dữ liệu giữa search index và database bị lệch sau sự cố mà không ai dám can thiệp — Hệ thống thiếu tài liệu quy định source of truth và thiếu câu lệnh dựng lại dữ liệu dẫn xuất độc lập.

Các bài học trong chương trình sẽ dẫn dắt bạn qua từng triệu chứng nêu trên để tìm ra nguyên nhân gốc rễ và áp dụng giải pháp tương ứng.

## Bạn sẽ học theo cách nào

- **Tiếp cận từ tình huống thực tế** — Mỗi bài học đều mở đầu bằng một triệu chứng kỹ thuật có thật trên dashboard giám sát, dòng log lỗi hoặc hóa đơn hạ tầng để bạn hiểu rõ vấn đề trước khi tìm giải pháp.
- **Minh họa qua sơ đồ và phép tính** — Từng bước phân tích đều đi kèm số liệu cụ thể, sơ đồ request path rõ ràng và đánh dấu chính xác vị trí các thành phần lưu giữ state.
- **Củng cố kiến thức qua bài tập định lượng** — Các bài học trọng tâm đều tích hợp câu hỏi tính toán giúp bạn tự tay áp dụng công thức Little’s Law, tính error budget và xác định hit ratio.
- **Thực hành trên chính dự án đang làm** — Mỗi chặng học gợi ý bài tập để bạn áp dụng trực tiếp vào hệ thống hiện tại, từ việc vẽ đường đi dữ liệu, lập bảng constraint cho tới soạn thảo tài liệu ADR.

## Khóa học dành cho ai

1. **Backend developer** — Bạn cần đưa ra quyết định kỹ thuật tự tin về việc khi nào cần thêm cache, queue hay read replica và ước lượng chính xác sức chịu tải của hệ thống trước mỗi đợt tăng lưu lượng.
2. **Kỹ sư phụ trách kiến trúc** — Bạn cần phương pháp so sánh các giải pháp kỹ thuật dựa trên số liệu đo lường khách quan và lưu vết quyết định qua tài liệu kiến trúc chuẩn mực.
3. **Kỹ sư vận hành hệ thống tăng trưởng** — Bạn đang quản lý các dịch vụ có tải và dữ liệu tăng dần theo thời gian, cần nhận diện sớm bottleneck đầu tiên để can thiệp đúng chỗ.

## Những điều cần lưu ý

- **Không đi sâu vào cấu hình chi tiết của từng phần mềm** — Khóa học không hướng dẫn thiết lập cụ thể cho Kubernetes, thuật toán xóa cache chuyên sâu hay cơ chế quorum phân tán, mà tập trung vào năng lực phân tích điều kiện sử dụng và đánh giá tradeoff kỹ thuật.
- **Không thay thế cho bước load test thực tế** — Các công thức ước lượng nhanh giúp bạn định hình quy mô ban đầu, nhưng sức chịu tải thực tế luôn cần được đối chiếu và kiểm chứng qua dữ liệu đo đạc trên môi trường chạy thử.
- **Số liệu trong bài mang tính minh họa phương pháp** — Các giá trị request/giây hay thời gian xử lý được xây dựng để làm rõ logic tính toán, bạn cần thay thế bằng thông số đo đạc từ hệ thống thực tế của mình.

## Bắt đầu từ đâu

Bài học mở đầu đặt hai bản thiết kế đối lập lên bàn cân: một kiến trúc cồng kềnh bảy thành phần gánh mức tải 30 request/giây, và một hệ thống tối giản bị sập khi lưu lượng chạm mốc 2.000 request/giây. Bạn sẽ thấy rõ một bản thiết kế tốt không đo bằng số lượng ô công nghệ phức tạp, mà được quyết định bởi việc làm rõ requirement, tải cao điểm và constraint kỹ thuật ngay từ những dòng đầu tiên.

## Chương trình

- Thiết kế hệ thống bắt đầu từ requirement, tải cao điểm và constraint (miễn phí)
- Request đi qua những chặng nào và state đang nằm ở đâu (miễn phí)
- Đọc p99, throughput, error rate và saturation trên dashboard (miễn phí) · quiz
- Tính năng qua hết test vẫn không dùng được vì thiếu non-functional requirement
- Ghi rõ constraint để loại bớt phương án trước khi so sánh
- Thay yêu cầu “nhanh và luôn chạy” bằng SLO và error budget
- Mô tả workload bằng tải cao điểm theo từng phút, không chỉ bằng số trung bình · quiz
- Ước lượng số máy, dung lượng và băng thông trước khi làm tính năng · quiz
- Source of truth: dữ liệu nào là gốc, dữ liệu nào dựng lại được
- Khi nào cần đặt load balancer, reverse proxy hay API gateway trước app · quiz
- Khi nào cần cache và nó gánh bớt được bao nhiêu tải đọc cho database · quiz
- Dùng queue để API không phải chờ những việc xử lý lâu · quiz
- Read replica gánh bớt tải đọc cho database primary · quiz
- Partition khi một bảng quá lớn và sharding khi một máy không ghi kịp · quiz
- Đưa file và ảnh ra khỏi database bằng object storage và CDN · quiz
- Hệ thống lớn dần thì thêm thành phần nào, khi nào và vì sao
- Thiết kế dịch vụ rút gọn link từ requirement tới kiến trúc · kit cho agent
- Thêm instance mà throughput không tăng thì bottleneck nằm ở đâu · quiz
- Lỗi ở một service phụ lan ra cả hệ thống như thế nào · quiz
- Lưu hàng triệu đơn hàng mỗi ngày mà báo cáo không làm chậm việc đặt hàng · kit cho agent
- Thiết lập hai phương án thiết kế khác nhau cho cùng một yêu cầu
- So sánh hai phương án thiết kế bằng số liệu thay vì ưu nhược điểm
- Ghi lại quyết định kiến trúc để một năm sau vẫn biết vì sao
- Thiết kế lại hệ thống khi flash sale đẩy tải lên gấp 40 lần · kit cho agent