---
title: "Diagram Director: template Grok Bot vẽ sơ đồ system design có chuyển động"
description: "Diagram Director là template Grok Bot vẽ sơ đồ system design có chuyển động; mọi con số phải nằm trong solution sheet trước khi dựng diagram."
canonical: "https://200lab.io/blog/grok-bot-diagram-director"
published: "2026-11-01T03:49:02Z"
updated: "2026-11-01T03:52:37Z"
authors: ["Mỹ Ngọc"]
tags: ["Agent", "AI", "Tips and tricks", "Grok Bot", "System Design"]
reading_minutes: 9
access: "public"
---

Khi mới học system design, mình hay vẽ hộp và mũi tên đứng yên trên bảng trắng. Sơ đồ có đủ service, database và cache, nhưng nhìn vào vẫn khó thấy request chạy đi đâu, chỗ nào dễ nghẽn, hay một node sập thì cả hệ thống phản ứng ra sao.

Gần đây anh Việt Trần, founder của 200Lab.io, tạo và chia sẻ một template Grok Bot tên là Diagram Director. Mình chưa tự chạy template này, nhưng đã đọc bộ kit gốc và mở file demo sơ đồ hệ thống chịu tải cao do bot kiến trúc của anh Việt dựng ngày 30/10/2026, rồi chạy lại bộ kiểm tra của kit trên file đó.

## Diagram Director là gì: template Grok Bot vẽ sơ đồ hệ thống có chuyển động

Theo [trang template Diagram Director](https://x.ai/bot/9--JXrTRkBSopsfj0vCj1), bot biến mô tả một hệ thống phần mềm hoặc một quy trình nghiệp vụ thành sơ đồ HTML có chuyển động: kiến trúc, luồng request, scale, queue, caching. Kết quả là một file HTML tự chứa, được kiểm tra bằng các quality gate tự động trước khi giao.

Bot xây trên bộ kit Diagram Director của 200Lab.io, một agent skill vẽ sơ đồ bằng SVG và chuyển động CSS. Sơ đồ không chỉ liệt kê các khối mà cho thấy hệ thống chạy thế nào: gói tin chạy trên đường nối, queue đầy dần, node đổi trạng thái. Kiểu vẽ tự do, không theo chuẩn UML, và không dùng cho biểu đồ số liệu hay mockup giao diện.

## Lấy template Grok Bot Diagram Director

Bạn mở trang template rồi bấm "Add to Grok Bot". Trang có lưu ý đây là bot do bên thứ ba tạo và có thể hành động thay bạn, nên bạn đọc kỹ trước khi thêm.

Sau khi thêm, bot tự tải và kiểm tra bộ kit, rồi hỏi ba câu: bạn hay vẽ hệ thống phần mềm hay quy trình, có muốn camera kèm caption không, và file vẽ xong để ở đâu.

> 👉 **[Lấy template Grok Bot Diagram Director](https://x.ai/bot/9--JXrTRkBSopsfj0vCj1)**

## Bộ kit Diagram Director có gì: dataset, 18 loại sơ đồ và 15 style

Bộ kit dùng license MIT, engine do anh Việt Trần viết. Bên trong có một dataset 377 dòng tra cứu ngay trên máy, để bot chọn loại sơ đồ, bố cục, màu và chuyển động.

| Nhóm dữ liệu | Số lượng | Dùng để làm gì |
| --- | --- | --- |
| Style | 15 | Phong cách hình ảnh, mỗi style có template gốc |
| Loại sơ đồ | 18 | Chọn đúng kiểu sơ đồ cho câu hỏi cần trả lời |
| Motion recipe | 30 | Công thức chuyển động CSS cho đường nối và node |
| Component | 95 | Các khối như service, database, cache, gateway |
| State | 22 | Trạng thái của node, ví dụ quá tải hay lỗi |
| Payload | 11 | Thứ đi trên đường nối, như request hay sự kiện |
| Dòng màu | 175 | Màu theo vai trò, có kiểm độ tương phản |
| Layout | 11 | Cách sắp xếp các khối trên sơ đồ |

Kit chia sơ đồ thành hai nhóm: system-design (mặc định) với khối là service, queue, database, cache, và process với khối là người, tài liệu, bước duyệt.

Loại sơ đồ có Request Lifecycle, Caching Strategy, Scaling Story, Queue Worker hay Comparison; style có Hand-Drawn Sketch, Blueprint, Neon Dark. Chữ trên sơ đồ đi theo ngôn ngữ của bạn; với tiếng Việt, kit dặn dùng font có đủ dấu như Be Vietnam Pro hoặc Inter.

## Quy trình 5 bước: giải bài toán trước, vẽ sơ đồ sau

Theo `SKILL.md`, bot không viết HTML ngay mà đi qua 5 bước theo thứ tự:

1. **Research và giải bài toán.** Bot hỏi trước những câu làm đổi kiến trúc như quy mô, đảm bảo, ràng buộc, rồi viết solution sheet: component, vai trò, số lượng, mọi con số, mỗi đảm bảo có một thành phần chịu trách nhiệm.
2. **Storyboard.** Chia thành từng beat; mỗi caption chỉ nhắc lại một dòng trong solution sheet.
3. **Chọn hệ thống hình ảnh.** Chọn style, layout và hình dạng khối.
4. **Build.** Dựng file HTML.
5. **Verify.** Render, xem từng khung trên contact sheet, chạy checklist, rà để mọi con số truy về được solution sheet.

![Quy trình giải bài toán trên solution sheet trước rồi mới vẽ sơ đồ sau.](https://assets.200lab.io/sha256/77/772ef9adc86af82e1837f4eca766bd4061a2dd4744fac2159b4309b277a08c45/generations/b0e7dde75712404f2cdb5ac8415373af0b4cd4d088af66d407a843267498fa14)

Xuyên suốt là "sync rule": solution sheet là nguồn sự thật duy nhất cho mọi chữ trên sơ đồ. Muốn đổi thông số thì sửa sheet trước rồi mới đổi hình; chữ nào không truy được về sheet thì không được giao.

Trước khi vẽ, bot hỏi bạn muốn beats mode, camera đi qua từng phần kèm caption, hay overview mode, một khung toàn cảnh với chấm request chạy trên đường nối. Không hỏi được thì bot mặc định overview.

## Ví dụ sơ đồ hệ thống chịu tải cao 500K RPS

File demo "High-load web system" dùng style Neon Dark, chạy beats mode với 12 bước, một vòng 62,4 giây. Nếu máy người xem bật reduce motion, file hiện luôn sơ đồ tĩnh đầy đủ.

Muốn xem sơ đồ ở kích thước đầy đủ, bạn mở [bản full của sơ đồ hệ thống chịu tải cao](https://assets.200lab.io/downloads/diagrams/high-load-system.html).

Mọi con số trong demo là giả định thiết kế để tập ước lượng, không phải số đo từ hệ thống thật: 10 triệu DAU, khoảng 1 triệu CCU lúc cao điểm, 500K RPS ở biên. Mục tiêu là p99 dưới 200 ms cho API đọc và availability 99,95%.

Đi kèm file HTML là solution sheet ghi đủ các bảng tính. Mình chạy lại `verify_all.py` của kit trên file demo, kết quả exit 0: 30 gate PASS, 8 gate N-A vì không áp dụng cho file này, 0 FAIL.

## Luồng đọc và luồng ghi trong sơ đồ hệ thống chịu tải cao

GeoDNS trả về PoP gần nhất, rồi CDN tự trả 80% request. Về tới origin chỉ còn 100K RPS, gồm 90K đọc và 10K ghi.

Rate limiter dùng token bucket 20 req/s mỗi user, burst 40, vượt thì nhận `HTTP 429`. Phần hợp lệ qua API gateway (L7 LB) tới app service stateless khoảng 100 pod, HPA co giãn từ 30 tới 150 pod theo CPU 60%.

![Sơ đồ tách riêng luồng đọc và luồng ghi trong hệ thống chịu tải cao.](https://assets.200lab.io/sha256/c3/c3784763a1e832b58f6cae2f3f741c23e38a06ef87d94caf8ad20ddf244426e8/generations/11c24a4175470377de0748fbe237ab1a77777385ac4ccfc51322b9107a6b052e)

### Luồng đọc: CDN, Redis và read replica

App đọc Redis Cluster (6 primary, 6 replica) theo kiểu cache-aside, giả định hit 95%. Phần miss là 5% của 90K, tức 4,5K QPS, đi qua circuit breaker xuống read replica. Postgres chia 8 shard theo `user_id`, mỗi shard 2 read replica, tổng 16 replica, mỗi replica gánh khoảng 280 QPS. Truy vấn tìm kiếm sang thẳng search cluster 3 node.

### Luồng ghi: outbox, Kafka và worker

10K lượt ghi mỗi giây chia về 8 shard, mỗi primary khoảng 1,25K ghi/s. Cùng transaction ghi dữ liệu, app ghi thêm một dòng outbox. Relay đọc outbox, đẩy sự kiện vào Kafka (6 broker, RF 3, 48 partition, `acks=all`, key là `user_id` để giữ thứ tự), rồi 24 worker trong một consumer group cập nhật search index và gửi thông báo.

## Sơ đồ cho thấy gì khi có sự cố: rate limiter, circuit breaker, Kafka

Mọi lời gọi xuống database được bọc bằng [circuit breaker](https://200lab.io/blog/circuit-breaker-la-gi) với timeout 200 ms. Ở bước này, caption trên sơ đồ ghi: "Replica chậm quá 200 ms? Breaker mở: trả cache cũ, không treo cả pool." Theo solution sheet, khi breaker mở mà không có cache cũ để trả thì hệ thống trả `503`.

| Sự cố | Hệ thống phản ứng |
| --- | --- |
| Traffic tăng đột biến | Rate limiter cắt phần vượt bằng `HTTP 429`, HPA thêm pod cho app service |
| Read replica chậm | Quá 200 ms thì breaker mở, trả cache cũ hoặc `503`, không treo connection pool |
| Primary của một shard chết | Promote replica lên thay, chỉ 1/8 số user bị ảnh hưởng |
| Kafka broker chết | RF 3, `acks=all` và `min.insync.replicas=2` nên không mất sự kiện đã ack |
| Worker crash | Consumer group rebalance, đọc tiếp từ offset đã commit, nên worker phải [idempotent](https://200lab.io/blog/idempotency-key-la-gi) |

Solution sheet cũng ghi thẳng phần đánh đổi. Kiến trúc nhiều thành phần này dành cho tải lớn; hệ thống nhỏ hơn, dưới khoảng 5K RPS, nên bắt đầu với 1 Postgres kèm replica và Redis.

## Dùng Diagram Director khi học system design và chơi GonnaCrash

Mình thấy cái hay của Diagram Director nằm ở sync rule và mấy câu hỏi bot đặt ra trước khi vẽ. Hồi học system design, mình hay tiện tay vẽ thêm Kafka hay một lớp cache cho sơ đồ trông chuyên nghiệp, mà không tính xem throughput là bao nhiêu. Phải có solution sheet trước thì con số nào đưa vào diagram cũng cần lý do, và đảm bảo nào cũng có thành phần chịu trách nhiệm.

Cách làm này cũng hợp nếu bạn đang chơi [GonnaCrash](https://200lab.io/blog/game-system-design-gonnacrash-duoc-lam-nhu-the-nao), game kéo thả một hệ thống rồi xem nó trụ hay sập. Qua xong một màn, bạn có thể nhờ bot vẽ lại hệ thống vừa dựng để nhìn request chạy qua từng node, rồi tự kiểm lại phép tính của mình.

Lưu ý là con số trên sơ đồ chỉ đúng khi giả định đầu vào hợp lý. Sơ đồ chạy đẹp không thay được việc bạn tự ước lượng tải.

## Tự thử Diagram Director với Grok Bot qua các bước cơ bản

Bạn có thể làm theo 6 bước sau:

1. **Chọn một bài toán.** Xem lại hệ thống bạn đang học dở hoặc vừa dựng trong GonnaCrash, chọn một luồng quan trọng nhất.
2. **Thêm template.** Mở link ở mục "Lấy template Grok Bot Diagram Director" phía trên và bấm "Add to Grok Bot".
3. **Trả lời 3 câu khởi động.** Chờ bot cài kit xong rồi trả lời ba câu hỏi ở trên.
4. **Mô tả hệ thống kèm con số.** Nhắn bot các khối chính và số giả định: người dùng, RPS, tỷ lệ đọc ghi, mục tiêu độ trễ.
5. **Chọn chế độ xem.** Chọn beats mode nếu muốn camera dẫn qua từng bước có caption, hoặc overview mode nếu chỉ cần nhìn toàn cảnh.
6. **Đối chiếu với solution sheet.** Mở file HTML, so từng con số với solution sheet; chỗ nào sai thì nhắn bot sửa sheet trước rồi vẽ lại.

Sơ đồ có chuyển động và con số rõ ràng giúp bạn thấy điểm nghẽn nhanh hơn những chiếc hộp đứng yên. Nếu bạn muốn luyện cách ước lượng tải và chọn load balancer, cache, queue, replication cho đúng trước khi vẽ những hệ thống lớn, bạn có thể tham khảo khóa học bên dưới tại 200Lab.

![Thiết kế hệ thống - ước lượng tải, load balancer, cache, queue, replication và partitioning](https://assets.200lab.io/sha256/0b/0b217d1bba119926a99dc02291da7d2364e83af165cddc8cc1e154a95f113634/generations/2b1ce89b70dc743a017321ed547b1217eabb7a6a0cb5f45746c5b4ebe8fb0357)

- [Thiết kế hệ thống - ước lượng tải, load balancer, cache, queue, replication và partitioning](https://200lab.io/courses/thiet-ke-he-thong-uoc-luong-tai-load-balancer-cache-queue-replication-va-partitioning.md)

## Đọc thêm

- [Thử dùng Jev gánh việc chọn lọc mỗi sáng để Grok Bot đỡ tốn token](https://200lab.io/blog/jev-grok-bot-decisions.md): Jev của TypeSafe AI giúp Grok Bot chọn lọc và ra quyết định bằng JSON xác suất: lọc tin, phân loại tin nhắn khách, kiểm tra bản nháp, giảm token mỗi ngày.
- [Extension Claude Code giả mạo trên Cursor Marketplace: cách kiểm tra máy](https://200lab.io/blog/claude-code-extension-cursor-ssh-backdoor.md): Extension Claude Code giả mạo trên Cursor Marketplace cố cài backdoor SSH lên macOS, Windows. Gỡ extension thôi chưa đủ, phải kiểm tra key lạ trong máy.
- [Self Evolution: cách để Grok Bot tự cải tiến liên tục từ kinh nghiệm làm việc và người dùng](https://200lab.io/blog/grok-bot-self-evolution.md): Self Evolution giúp Grok Bot rút bài học từ việc hằng ngày, nhưng bot chỉ học khi có ghi log kèm bằng chứng và thay đổi rủi ro vẫn chờ bạn duyệt.
- [OpenAI công bố hệ thống giám sát AI agent sau vụ Hugging Face](https://200lab.io/blog/openai-ai-agent-monitoring-system.md): Giám sát AI agent ở OpenAI có 4 lớp, dựng sau vụ agent thoát sandbox. Hãng làm model còn phải soi agent, người giao việc càng cần chỗ xem lại bot làm gì.
- [Cách đặt Grok Bot gửi bản tin cuối ngày nhắc việc cho chủ shop](https://200lab.io/blog/grok-bot-daily-digest-routine.md): Bản tin cuối ngày giúp người bán một mình gom việc còn treo. Với routine của Grok Bot, bot chỉ đọc bảng và nhắc việc theo lịch, chủ shop vẫn tự quyết định.
- [Mọi bài viết chủ đề Agent](https://200lab.io/blog/tags/agent.md)

Toàn bộ nội dung: https://200lab.io/llms.txt