---
title: "Vượt màn GonnaCrash - capacity, scale out, sharding, multi-region, RAG, LLM routing và agent harness"
description: "Khóa nền tảng về tư duy system design đi cùng các màn của game GonnaCrash, xoay quanh thói quen đếm tải, chi phí và token qua từng node trên board. Bạn hiểu được cơ chế mà từng màn kiểm tra, từ hệ thống tải cao đến RAG và Agent Harness, để tự tìm ra chỗ cần sửa khi màn báo Failed."
canonical: "https://200lab.io/courses/vuot-man-gonnacrash"
type: "course"
course_type: "course"
learning_type: "free_form"
published: "2026-10-20T06:39:30Z"
students: 0
---

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

Ở [trang GonnaCrash của 200Lab](https://200lab.io/mini-solutions/gonnacrash), bạn dựng hệ thống trên board rồi bấm Run cho traffic đổ vào; lượt Run nào hỏng thì game chỉ ra node gục đầu tiên. Game miễn phí, mỗi ngày cho **100** lượt Run, có bản tiếng Việt và tiếng Anh, dùng được trên cả máy tính lẫn điện thoại. Bạn dùng tài khoản 200Lab để chơi và lưu tiến trình.

Mỗi màn GonnaCrash chấm board theo nhiều mục tiêu cùng lúc, từ tỷ lệ request được phản hồi, latency đến chi phí, còn màn AI chấm thêm tỷ lệ đúng và độ an toàn. Nếu chỉ thêm thành phần theo cảm giác, bạn dễ nâng tier nhầm node mà màn vẫn báo Failed, hoặc sửa được mục tiêu này thì board lại trượt mục tiêu khác. Khóa học giải thích cơ chế mà từng màn kiểm tra, để bạn nhìn ra chỗ nghẽn rồi tự sửa thiết kế.

- **Tính trước tải và chi phí** — Bạn đếm được tải vào từng node, chi phí mỗi tháng và số token mỗi câu, thay vì đoán node nào cần máy lớn hơn.
- **Tìm đúng node đang nghẽn** — Từ dòng lý do và node chuyển đỏ, bạn quyết định nên nâng tier, scale out, thêm cache, đặt queue hay thêm read replica.
- **Chia dữ liệu và chọn region** — Bạn biết khi nào cần chỉnh connection pool, dùng partition hay sharding, hoặc đưa hệ thống sang multi-region.
- **Thiết kế đường gọi model** — Bạn đặt bước chọn dữ liệu, reranker, LLM routing và giới hạn token vào đúng chỗ, để bot trả lời đủ đúng mà không vượt ngân sách mỗi câu.
- **Đặt guardrail cho tính năng AI** — Bạn dựng được nhiều lớp lọc tin độc, bước kiểm tra JSON model trả về và cách tách riêng tài liệu của từng công ty.
- **Kiểm soát agent chạy nhiều bước** — Bạn ước lượng được tỷ lệ đúng của task tụt thế nào theo số bước, lưu state để job chạy tiếp sau crash và chọn ra lệnh cần người duyệt.

Đây là khóa nền tảng về tư duy system design, không gắn với ngôn ngữ lập trình nào, và lấy board của game làm chỗ thực hành.

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

Cả khóa học xoay quanh thói quen đếm trước khi bấm Run, tức là tính xem request, dữ liệu, tiền và token dồn vào từng thành phần trên board nhiều tới đâu. Mỗi màn GonnaCrash đặt ra bài toán thiết kế riêng, và các màn đi dần từ ứng dụng web cơ bản, qua hệ thống tải cao, tới ứng dụng AI và Agent Harness. Khóa học đi theo đúng thứ tự bốn world của game, nên bạn hiểu cơ chế trên board mô phỏng trước, rồi xem cơ chế ấy chạy thế nào ở sản phẩm thật.

### 1. World “Nền tảng”: đường đi của request, tải đọc, tải ghi và độ sẵn sàng

World đầu tiên mở ra bằng câu hỏi vì sao Users không nối thẳng vào database mà cần App Server, rồi Load Balancer, reverse proxy hay API gateway đứng trước. Khi lượng truy cập tăng đột ngột, bạn đếm xem cache và read replica gánh bớt được bao nhiêu tải đọc, và vì sao trên board chỉ có một database primary thì lượt ghi vẫn dồn hết về primary. Khi app có thêm upload, giỏ hàng và tìm kiếm, các bài đưa file và ảnh ra object storage kèm CDN, chuyển những việc xử lý lâu như gửi email sang queue, và đặt state đúng chỗ để dọn cache không làm mất giỏ hàng. Cuối world là ca trực production, từ health check để Load Balancer không gửi request vào máy đã treo, rolling deploy để lúc nào cũng còn máy phản hồi, tới chuyện vì sao có backup rồi mà hỏng ổ đĩa vẫn mất tới cả ngày dữ liệu. Rate limiting thì giữ cho một client không làm chậm mọi người dùng khác.

### 2. World “Hệ thống tải cao”: database, traffic tăng đột biến và quy mô toàn cầu

Sang world thứ hai, database và độ trễ network giữa các châu lục trở thành chỗ nghẽn. Bạn tính connection pool nên lớn bao nhiêu, vì sao chỉ **120** lượt mở trang mỗi giây đã làm database tier XL quá tải, và khi nào một máy không ghi kịp nên phải shard dữ liệu, kể cả trường hợp chia theo tháng làm mọi lệnh ghi dồn vào một shard. Khi traffic ập đến, các bài giải thích retry với backoff (giãn dần khoảng cách giữa các lần thử), cache stampede, cách cô lập request nặng để nó không chiếm hết connection, circuit breaker và thời gian máy mới khởi động lúc autoscale. Ở quy mô toàn cầu, bạn đặt App Server và dữ liệu gần người dùng EU, quyết định request đi đâu khi một vùng sập và chọn replica nào để promote khi primary chết. Bạn cũng cân nhắc ghép timeline lúc đọc hay ghi sẵn lúc đăng bài, rồi hạ tier những node đang thừa sức để chi phí mỗi triệu request không vượt mục tiêu.

### 3. World “Ứng dụng AI”: chi phí token, RAG, LLM routing, an toàn và vận hành

Từ world thứ ba, board có thêm LLM Provider, và bài toán không chỉ là request mỗi giây mà còn có tiền token, thời gian chờ tới khi chữ đầu tiên hiện ra, tỷ lệ đúng và độ an toàn. Bạn tìm ra tiền token đến từ đâu, dùng streaming để người dùng không phải chờ model viết xong mới thấy chữ, hiểu vì sao hai provider cùng model vẫn trả lỗi **429**, và dùng lại câu trả lời cũ tới đâu thì bot không trả lời nhầm. Để chatbot bớt đoán mò khi được hỏi về tài liệu nội bộ, các bài đi vào RAG, reranker và bước chọn dữ liệu trước khi gửi cho model. Phần cuối world đưa AI vào sản phẩm, với LLM routing để câu hỏi dễ không bị tính theo giá của model mạnh nhất, eval trước khi ship prompt mới, cộng độ trễ từng chặng của tính năng giọng nói, và guardrail nhiều lớp để chặn tin độc lẫn giữ cho bot không lộ tài liệu của công ty này cho công ty khác.

### 4. World “Agent Harness”: task nhiều bước, rào chắn và nền tảng cho agent

Ở world cuối, model không chỉ trả lời một lượt mà tự gọi tool qua nhiều bước để làm xong task. Bạn đếm agent gọi model bao nhiêu lần cho task sửa lỗi nhỏ, tính tỷ lệ đúng của cả task tụt thế nào khi số bước tăng, và lưu state để job bị crash giữa chừng biết chạy tiếp từ đâu. Vì agent có quyền gọi tool chạm vào code và dữ liệu production, các bài tiếp theo tính xem bao nhiêu task chạy phải lệnh nguy hiểm khi cứ **200** lệnh tool có một lệnh như vậy, lệnh nào mới thật sự cần người duyệt và agent cầm token production cần mấy lớp chặn. World khép lại bằng nền tảng cho agent, từ chia task cho nhiều sub-agent, chặn code hỏng trước khi tới tay khách, tới idempotency key để khách không bị trừ tiền hai lần khi app retry. Cuối cùng, bạn tìm xem bước nào trong **12** bước của một task agent thật sự cần model lớn nhất.

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

Khi mới học lập trình, phần lớn chúng ta làm quen với ứng dụng chỉ có App Server đọc ghi vào database. Đến bài toán tải cao hay tính năng AI, điều cần biết lại là các thành phần phối hợp ra sao khi lượng truy cập tăng, khi một node sập, hay khi mỗi lần gọi model đều tính tiền theo token. Nếu chỉ đọc lý thuyết system design, bạn khó hình dung vì chưa từng thấy hệ thống của mình quá tải ở đâu.

200Lab làm GonnaCrash để bạn tự kéo các thành phần lên board, nối chúng lại, bấm Run và thấy ngay chỗ thiết kế còn thiếu. Nhưng khi màn báo Failed và một node chuyển đỏ, bạn rất dễ nâng tier, thêm đại một cache hay đổi sang model đắt nhất rồi bấm Run lại. Thử như vậy mà không đếm trước thì chi phí tăng lên, còn chỗ nghẽn thật có khi vẫn nằm nguyên ở node khác.

Khóa học này đi cùng bạn đúng lúc màn kết quả báo Failed. Bài viết cho màn ấy giúp bạn đếm lại tải, hiểu cơ chế nằm sau dòng lý do và thấy cơ chế đó ở sản phẩm thật. Từ đó bạn tự tính ra hướng sửa và giữ thói quen đếm trước khi thêm thành phần mới.

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

Khi màn báo Failed, nhiều người kéo ngay thành phần quen tên vào board, hoặc đổi tier cho node đầu tiên họ nghĩ tới. Họ thử từng thứ một mà không đếm trước. Cách thử ấy thường làm board kẹt ở mục tiêu chi phí, hoặc sửa lỗi này lại sinh ra lỗi khác.

- Bạn nâng App Server lên tier L mà màn vẫn báo Failed, còn Relational DB chuyển đỏ — mỗi lượt xem trang kéo theo **3** truy vấn đọc, nên database mới là node nhận tải vượt capacity.
- Bạn đã thêm cache mà màn vẫn báo quá tải vì lượt ghi — cache trên board chỉ đỡ tải đọc, còn mọi lệnh ghi vẫn đi thẳng xuống database primary duy nhất.
- Một App Server đã treo mà Load Balancer vẫn gửi request vào nó — health check TCP chỉ xem máy còn nhận kết nối hay không, nên không thấy app bên trong đã treo.
- Câu hỏi nào gửi vào chatbot cũng dễ mà chi phí mỗi câu vẫn vượt mức — ở màn này giá model quyết định gần hết chi phí, nên khi model rẻ đã đạt mọi rule thì chọn model mạnh chỉ làm mỗi câu đắt hơn.
- Bạn cho Vector DB lấy hẳn **20** đoạn tài liệu, rồi màn báo Failed vì chi phí mỗi câu — đoạn nào vào prompt cũng tốn token, nên cần reranker chấm lại nhiều ứng viên rồi chỉ giữ vài đoạn liên quan nhất.
- App Server retry ngay khi LLM Provider trả lỗi **429** — request bị từ chối vẫn bị tính vào trần token mỗi phút của cả tài khoản, nên retry chỉ dồn thêm request vào trần đã đầy.
- Agent hiếm khi sai ở từng bước mà task **12** bước vẫn hụt mức tỷ lệ đúng — trên board, task chỉ đúng khi mọi bước đều đúng và các bước sai độc lập với nhau, nên tỷ lệ đúng mỗi bước bị nhân với chính nó **12** lần.

Mỗi tình huống trên đều có bài giải thích bằng phép đếm tải, tiền hay token.

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

- **Mở đầu từ board Failed** — Bài viết cho game mở từ đúng board mà màn vừa báo Failed, kèm dòng lý do; bài mượn giữ nguyên tình huống và ví dụ gốc.
- **Sơ đồ và bảng đếm** — Bài vẽ đường đi của request hoặc dữ liệu, rồi ghi tải, chi phí hay số token của từng node vào bảng đếm.
- **Mỗi bài đọc riêng vẫn hiểu** — Bài viết cho game xoay quanh một cơ chế chính; bài tổng hợp ở cuối một số chương ghép các cơ chế đã gặp.
- **Cơ chế ở sản phẩm thật** — Sau phần đếm trên board, bài cho thấy cơ chế ấy ở sản phẩm thật, như database trên cloud hay API của model.

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

1. **Người đang chơi GonnaCrash** — Bạn vừa gặp màn báo Failed, mở bài từ chip “Bài nên đọc” và muốn hiểu cơ chế đứng sau để tự sửa board.
2. **Developer junior** — Bạn biết ứng dụng thường gồm server và database nhưng chưa học system design; khóa học không đòi học khóa nào trước.
3. **Sinh viên IT** — Bạn muốn thấy cache, queue, sharding, RAG hay guardrail thay đổi latency, chi phí và độ an toàn của sản phẩm ra sao.

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

- **Game chỉ mô phỏng đơn giản** — Đây là lesson chỉ dành cho người chơi game GonnaCrash. Vì game có mô phỏng đơn giản nên vui lòng không dùng các thông số game cho thực tế; bạn hiểu được cơ chế gốc để áp dụng ngoài game.
- **Bài không đưa lời giải** — Các bài không vẽ sẵn board qua màn, không đưa giá trị cuối cùng và không loại trừ phương án giúp bạn; bạn nhận được cơ chế và hướng sửa, còn lời giải là bước gợi ý cuối của game.
- **Có bài mượn từ khóa khác** — Một số bài lấy nguyên từ các khóa System Design và AI khác của 200Lab và vẫn giải thích đúng cơ chế mà màn tương ứng kiểm tra; khi muốn đi sâu hơn, bạn có thể học tiếp các khóa System Design.

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

Bài mở đầu trả lời câu hỏi “Vì sao nối Users thẳng vào database mà màn đầu vẫn báo Failed?”. Bài này đứng đầu vì nó giải thích đường đi của một request, lý do database cần App Server đứng trước, cách game chấm một lượt Run và cách đọc màn kết quả. Cuối bài là bản đồ của cả khóa học theo bốn world.

## Chương trình

- Vì sao nối Users thẳng vào database mà màn đầu vẫn báo Failed? (miễn phí)

### Bỗng dưng nổi tiếng

- Node chuyển đỏ vì quá tải: nâng tier cho node nào mới có ích?
- 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
- Đã thêm cache mà màn vẫn báo quá tải vì lượt ghi: cache đỡ được loại request nào?
- Read replica gánh bớt tải đọc cho database primary · quiz
- Cache bị dọn đúng lúc đông nhất thì lượt đọc đổ về đâu?

### Tính năng mới, rắc rối mới

- Đưa file và ảnh ra khỏi database bằng object storage và CDN · quiz
- Dùng queue để API không phải chờ những việc xử lý lâu · quiz
- Dọn cache xong thì khách nào cũng mất giỏ hàng: giỏ hàng phải lưu ở đâu?
- Đăng xong đã hai phút mà bài mới vẫn chưa hiện trong kết quả tìm kiếm
- Mỗi lượt upload video qua API làm mọi request khác chậm theo (miễn phí) · quiz
- Chỉ một zone mất điện mà cả hệ thống cũng sập theo

### Ca trực production

- Server đã treo, sao Load Balancer vẫn gửi request vào nó?
- Deploy khởi động lại mọi App Server cùng lúc: còn máy nào phản hồi người dùng?
- Request đi qua những chặng nào và state đang nằm ở đâu (miễn phí)
- Database hỏng ổ đĩa: có backup rồi, vì sao vẫn mất tới cả ngày dữ liệu?
- Dùng rate limiting để một client không làm chậm mọi người dùng khác · quiz
- Tuần ra mắt: một App Server treo đúng lúc team đang deploy, dư một máy có đủ không?

### Giải cứu database

- Connection pool nên lớn bao nhiêu và request nên chờ ở app hay trong database · quiz
- Vì sao chỉ 120 lượt mở trang cá nhân mỗi giây đã làm database tier XL quá tải?
- Partition khi một bảng quá lớn và sharding khi một máy không ghi kịp · quiz
- Chia database theo tháng làm mọi lệnh ghi dồn vào một shard · quiz · kit cho agent
- Vì sao một dòng đếm lượt xem làm chậm mọi trang sản phẩm? · quiz
- Primary chết thì nên promote replica nào · quiz
- Database đón Black Friday: connection không đủ, like dồn vào cùng một row và primary sập giữa đêm

### Khi traffic ập đến

- Lỗi nào nên retry, retry bao nhiêu lần và cách nhau bao lâu · quiz
- Cache stampede: một key hết hạn và hàng nghìn request cùng đổ xuống database · quiz
- Không để một loại request nặng chiếm hết connection của cả service · quiz
- Circuit breaker: ngừng gọi dependency đang lỗi thay vì lần nào cũng chờ timeout · quiz
- Đặt App Server ở EU đã đủ để người dùng EU mở trang nhanh chưa?
- Autoscale đã gọi thêm máy, vì sao lượt xem vẫn bị từ chối khi máy mới còn đang khởi động?

### Quy mô toàn cầu

- Chia dữ liệu theo nơi ghi trước khi bật multi-leader
- Vùng EU sập năm phút, request của người dùng EU sẽ đi về đâu?
- Ghép timeline lúc đọc hay ghi sẵn lúc đăng bài?
- Database đã có giá mới nhưng trang tìm kiếm vẫn hiện giá cũ
- Ảnh cũ ít ai mở có cần nằm ở storage class đắt nhất không?
- Chi phí mỗi triệu request vượt mục tiêu dù không node nào quá tải: node nào đang thừa sức?
- Chung kết World Cup: vùng EU sập đúng lúc bộ đếm lượt xem đang nóng nhất

### Chatbot lên sóng

- Chi phí mỗi câu của chatbot vượt mức dù câu hỏi nào cũng dễ: tiền token đến từ đâu?
- Người dùng có phải chờ model viết xong mới thấy chữ đầu tiên?
- Vì sao hai LLM Provider cùng model vẫn trả về lỗi 429?
- Prompt dài bắt bạn chờ lâu mới thấy chữ đầu tiên, còn prefix giữ nguyên thì được giảm giá (miễn phí) · quiz
- Câu hỏi cũ chỉ đổi vài chữ mà app vẫn trả tiền gọi model: dùng lại câu trả lời cũ tới đâu thì không trả lời nhầm?
- Chatbot còn trả lời được ai trong hai phút provider bị sập?

### Đừng bịa nữa

- Model phải đoán khi được hỏi về tài liệu nội bộ: bot cần gì để trả lời đúng, và đúng được tới đâu?
- Đoạn tài liệu cần tìm xếp thứ 15 thì bot trả lời theo đoạn nào?
- Gắn nhãn ticket có cần đến model biết viết văn không?
- Chọn dữ liệu cần thiết trước khi gửi cho model · quiz · kit cho agent
- Giới hạn token cho từng đối tác trên LLM gateway · kit cho agent

### AI trong sản phẩm

- Vì sao câu hỏi dễ cũng bị tính tiền theo giá của model mạnh nhất?
- Model trả JSON hỏng nên app không tạo được đơn: đổi sang model lớn hơn có hết lỗi không?
- Job embed chạy nền làm câu hỏi của nhân viên nhận lỗi 429
- Bot trả lời sai nhiều hơn hẳn từ khi prompt mới được ship: vì sao không ai biết trước?
- Ra mắt tính năng AI: card sai size, JSON hỏng và lỗi 429 trong cùng một buổi livestream

### An toàn và vận hành

- Guardrail đang bắt 97% tin nhắn độc, vì sao bỗng để lọt nhiều hơn hẳn?
- Câu trả lời của chatbot kém đi dù không ai sửa dòng code nào
- Trả tiền theo token hay thuê GPU chạy model riêng?
- Bot hỏi đáp trích nguyên văn tài liệu của một công ty khác: đoạn tài liệu đó lọt vào từ đâu?
- Khách nói xong phải chờ mấy giây mới nghe tiếng trả lời: thời gian chờ ấy cộng từ những bước nào?
- Gửi lại cả lịch sử chat thì đắt, bỏ đi thì chatbot quên chuyện cũ
- Ngày ra mắt toàn cầu: model đổi phiên bản, provider sập và bot lộ tài liệu của công ty khác

### Agent chạy đến cùng

- Một task sửa lỗi nhỏ, agent gọi model bao nhiêu lần?
- Agent sai ở bước 9 là cả task hỏng theo: tỷ lệ đúng tụt thế nào khi task có nhiều bước?
- Job nhiều bước bị crash giữa chừng thì chạy tiếp từ đâu · quiz

### Rào chắn cho agent

- Bao nhiêu task của agent chạy phải lệnh nguy hiểm nếu cứ 200 lệnh tool có một?
- Được phép chạy chưa có nghĩa là được chạm vào mọi thứ · quiz · kit cho agent
- Hàng chờ người duyệt dài thêm theo từng giờ: lệnh nào mới thật sự cần con người duyệt?
- Agent cầm token production thật cần mấy lớp chặn để không xóa nhầm?

### Xây nền tảng agent

- Chia task cho nhiều sub-agent: nhanh hơn bao nhiêu, tốn thêm bao nhiêu?
- Cứ sáu task agent làm thì có một task sai: chặn code hỏng thế nào trước khi nó tới tay khách?
- Chọn partition key để event của cùng một đơn được xử lý đúng thứ tự · quiz · kit cho agent
- Idempotency key giúp retry mà không trừ tiền khách hai lần · quiz
- Bước nào trong mười hai bước của task agent thật sự cần model lớn nhất?