Đọc kiến trúc Container C4 Level 2: Cloudflare, Gateway, Queue và Monitoring — để AI không dắt mũi khi vibecoding

Trong mô hình C4, Level 1 (System Context) chỉ cho bạn biết ai dùng hệ thống và hệ thống nói chuyện với ai. Level 2 — Container — đi sâu vào bên trong: hệ thống gồm những container nào và chúng nói chuyện với nhau ra sao. Bài hướng dẫn của trang Code Web Không Khó đọc một kiến trúc web thực tế theo đúng trục đó, từ ngoài vào trong: Cloudflare ở cửa ngõ, Gateway chia luồng theo subdomain, Backend có API realtime và hàng đợi, tầng dữ liệu PostgreSQL – MinIO – Redis, và một hệ thống giám sát Prometheus – Grafana – Loki chạy hoàn toàn nội bộ. Hiểu được sơ đồ này là hiểu hết hệ thống — và là điều kiện để làm việc với AI mà không bị AI dắt mũi khi vibecoding.

Trả lời nhanh

• C4 Level 2 (Container) bóc tách bên trong hệ thống thành các container — các ứng dụng, dịch vụ và kho dữ liệu chạy độc lập được — và chỉ rõ chúng giao tiếp với nhau như thế nào; đây là bước tiếp theo sau Level 1 (System Context: ai dùng hệ thống, hệ thống nối với hệ thống ngoài nào).
• Luồng request trong kiến trúc mẫu đi từ ngoài vào trong: Internet → Cloudflare (chặn bot và request độc hại, chỉ mở HTTPS cổng 443, tắt HTTP 80 trên production) → mạng LAN nội bộ → Gateway (Nginx hoặc Kong) làm reverse proxy → các frontend và dịch vụ bên trong → tầng dữ liệu → Monitoring giám sát tất cả.
• Gateway định tuyến theo subdomain: tên miền chính vào User Frontend; subdomain admin vào Admin Frontend; subdomain app vào App; thêm một service Link Base riêng; và một đường MCP riêng (qua subdomain mcp) để AI có thể tương tác với hệ thống.
• Backend gồm API và hàng đợi: API viết bằng Express + Socket để xử lý realtime (chat, thông báo, cập nhật trạng thái đơn hàng — có thể thay bằng Go + Gin), và Queue dùng BullMQ để xếp hàng xử lý tác vụ, tránh sập server khi nhiều người dùng ập vào cùng lúc và không để mất tác vụ.
• Tầng dữ liệu và giám sát: PostgreSQL lưu dữ liệu chính (người dùng, đơn hàng, sản phẩm); MinIO lưu file, ảnh, video như một S3 tự host; Redis làm cache. Monitoring — Prometheus (đo hiệu năng), Grafana (dashboard), Alertmanager (báo động qua bot), Loki (gom log) — chạy ở cổng nội bộ, bên ngoài không truy cập được.

C4 Level 2 (Container) là gì?

Mô hình C4 là cách vẽ kiến trúc phần mềm theo nhiều mức phóng to dần. Level 1, System Context, là mức ngoài cùng: nó cho thấy người dùng là ai, hệ thống của bạn nằm ở đâu và nó nói chuyện với những hệ thống bên ngoài nào. Level 2, Container, phóng to vào chính hệ thống của bạn: bên trong có những container nào — mỗi container là một khối chạy độc lập được như một ứng dụng web, một API, một cơ sở dữ liệu hay một dịch vụ nền — và chúng giao tiếp với nhau bằng gì, theo chiều nào.

Giá trị của Level 2 nằm ở tính trực quan: nhìn vào sơ đồ là hình dung được toàn bộ hệ thống — request đi vào từ đâu, rẽ nhánh ở đâu, dữ liệu nằm ở đâu, và phần nào đang giám sát phần nào. Theo tác giả bài gốc, đây cũng là nền tảng để làm việc với AI trong thời vibecoding: người đọc được kiến trúc thì kiểm soát được hệ thống, thay vì để AI tự vẽ và tự quyết.

Đọc kiến trúc từ ngoài vào trong như thế nào?

Bài hướng dẫn đọc sơ đồ theo đúng chiều đi của một request, gồm bảy chặng:

Chặng	Thành phần	Vai trò trong kiến trúc mẫu
1. Cửa ngõ Internet	Cloudflare	"Bức tường thành" đầu tiên: chặn bot và request độc hại từ bên ngoài, không cho truy cập thẳng vào server; request đi qua HTTPS cổng 443, production tắt hẳn cổng HTTP 80
2. Mạng nội bộ	LAN (ô màu trắng trong sơ đồ)	Mọi service bên trong giao tiếp với nhau qua mạng LAN này; người ngoài không can thiệp được — theo tác giả, đây là lớp bảo vệ vững chắc nhất của hệ thống
3. Người gác cổng	Gateway — Nginx (hoặc Kong)	Reverse proxy điều hướng request vào đúng service bên trong, chia theo subdomain
4. Backend	API (Express + Socket) + Queue (BullMQ)	API xử lý nghiệp vụ và realtime; Queue xếp hàng tác vụ để hệ thống không sập khi tải đột biến và không mất việc
5. Tầng dữ liệu	PostgreSQL + MinIO + Redis	Dữ liệu chính, file/ảnh/video và cache — mọi thao tác của Backend đều lưu về tầng này
6. Giám sát	Prometheus + Grafana + Alertmanager + Loki	Đo hiệu năng, vẽ dashboard, báo động và gom log; chạy ở cổng internal, bên ngoài không vào được
7. Đẩy ra ngoài	Discord / Google Drive / Backup	Thông báo đẩy ra các nền tảng bên ngoài; dữ liệu và bản sao lưu được đẩy ra khỏi server để server sập vẫn còn dữ liệu

Gateway chia luồng theo subdomain ra sao?

Sau Cloudflare, mọi request đều tới Gateway — trong kiến trúc mẫu là Nginx, và tác giả lưu ý có thể dùng Kong thay thế. Gateway làm nhiệm vụ reverse proxy: điều hướng request vào đúng service bên trong dựa trên subdomain:

• Tên miền chính → User Frontend, nơi người dùng cuối truy cập.
• Subdomain admin → Admin Frontend cho quản trị.
• Subdomain app → ứng dụng (App).
• Link Base → một service riêng.
• Subdomain mcp → đường MCP riêng cho AI, để AI có thể can thiệp vào hệ thống.

Theo tác giả, MCP (Model Context Protocol) là một xu hướng đáng chú ý: việc dành sẵn một container và một đường vào riêng cho AI ngay trong kiến trúc Level 2 cho thấy hệ thống được thiết kế với giả định AI là một "người dùng" đặc biệt của hệ thống, thay vì một tiện ích gắn thêm về sau.

Backend gồm những gì: API realtime và Queue?

Bên trong Backend của kiến trúc mẫu có hai khối chính. Thứ nhất là API viết bằng Express + Socket: Socket phục vụ các nhu cầu realtime như chat, thông báo và cập nhật trạng thái đơn hàng ngay lập tức; tác giả cũng ghi chú có thể thay bằng Go + Gin nếu muốn. Thứ hai là Queue dùng BullMQ để xử lý hàng đợi tác vụ.

Tác giả ví Queue như quán gà rán: 100 người vào cùng một lúc thì xếp hàng — ai vào trước làm trước, ai vào sau làm sau. Queue xử lý đa tác vụ theo thứ tự và có kỹ thuật để không bị mất tác vụ trong hàng đợi. Không có Queue, 100 người ập vào cùng lúc là server sập. Đây là lý do hàng đợi xuất hiện như một container riêng trong sơ đồ Level 2, thay vì bị gộp chung vào API: nó có vai trò, nhịp xử lý và cách hỏng hoàn toàn khác với phần xử lý request trực tiếp.

Tầng dữ liệu gồm những thành phần nào?

Mọi thao tác ở Backend đều được lưu ở tầng Data/Infra gồm ba container:

• PostgreSQL: lưu dữ liệu chính — người dùng, đơn hàng, sản phẩm.
• MinIO: lưu file, ảnh, video — giống như một S3 tự host. Một mẹo tác giả chia sẻ: khi người dùng gọi một tấm ảnh, request đi thẳng vào MinIO qua Gateway, và Gateway cache lại tấm ảnh đó; lần sau nạp lại sẽ rất nhanh vì ảnh đã thành nội dung tĩnh được cache.
• Redis: caching — lưu tạm dữ liệu hay dùng để tải nhanh.

Cách tách ba container này phản ánh ba bản chất dữ liệu khác nhau: dữ liệu quan hệ cần toàn vẹn (PostgreSQL), file lớn cần lưu trữ đối tượng rẻ và tự chủ (MinIO), và dữ liệu tạm cần tốc độ (Redis).

Hệ thống Monitoring được tổ chức thế nào?

Monitoring trong kiến trúc mẫu chạy ở các cổng internal — bên ngoài không truy cập được — và gồm bốn thành phần:

• Prometheus: cắm trực tiếp vào PostgreSQL, Redis, Node và nhiều thành phần khác để đo hiệu năng.
• Grafana: vẽ dashboard để nhìn CPU, RAM, lượng request và các chỉ số khác.
• Alertmanager: khi có vấn đề, nó đẩy thông báo vào bot để người vận hành biết ngay. (Trong sơ đồ Hình 2 của tác giả, tầng này còn có Tempo cho truy vết phân tán (distributed tracing), và cảnh báo của Alertmanager được đẩy qua Telegram Bot API.)
• Loki: thu thập toàn bộ log của hệ thống. Giá trị thực tế mà tác giả nhấn mạnh: khi người dùng báo lỗi mà hệ thống không rõ nguyên nhân, bạn tìm trên Loki, cho AI đọc chính log đó — AI tìm ra lỗi và sửa giúp.

Điểm đáng học ở đây là Monitoring được vẽ như một tầng ngang giám sát mọi container khác, chứ không phải một tính năng của riêng Backend — và việc nó bị khóa sau mạng nội bộ là một quyết định bảo mật có chủ đích trong kiến trúc.

Làm sao giữ kiến trúc luôn đúng khi làm việc với AI?

Đây là thông điệp tác giả muốn nhắn gửi nhất. Khi đã dựng được kiến trúc như trên, bài toán tiếp theo xuất hiện ngay: làm việc với AI bằng prompt mỗi ngày, làm sao để kiến trúc này luôn được cập nhật và không bị AI vẽ lung tung theo thời gian?

Cách làm được chia sẻ là tạo một thư mục Rules chứa toàn bộ quy trình phát triển phần mềm của dự án. AI sẽ tuân thủ theo Rules đó trong mọi lần làm việc sau — đó là cách tác giả giữ cho kiến trúc luôn đúng chuẩn đã định, thay vì để mỗi phiên làm việc với AI lại "phát minh" lại hệ thống theo một hướng khác. Ảnh chụp màn hình tác giả chia sẻ cho thấy cách triển khai cụ thể: một lệnh tùy chỉnh /architecture-plan đặt trong hệ thống lệnh của dự án, giao cho AI vai trò kiến trúc sư trưởng (Principal Software Architect) để tạo mới/cập nhật tài liệu kiến trúc chính thức architecture.md, với mọi nhận định phải có bằng chứng tới mức file:dòng trong mã nguồn — không đoán, không bịa. Nói cách khác: sơ đồ Level 2 cho con người cái nhìn toàn cảnh, còn thư mục Rules là cách ép AI cũng phải tôn trọng cái nhìn toàn cảnh đó.

Tóm lại, chuỗi kiến trúc mẫu khép lại như sau: User → Cloudflare (chặn bot) → Gateway Nginx/Kong (chia subdomain) → Frontend User/Admin/App + MCP + API + Queue → Data Tier (PostgreSQL + MinIO + Redis) → Monitoring (Prometheus + Grafana + Loki) giám sát tất cả, với dữ liệu sao lưu và thông báo được đẩy ra ngoài (Discord, Google Drive, Backup) ở đầu ra.

Câu hỏi thường gặp

C4 Level 2 khác gì Level 1?

Level 1 (System Context) nhìn hệ thống từ bên ngoài: ai sử dụng nó và nó kết nối với những hệ thống ngoài nào. Level 2 (Container) phóng vào bên trong hệ thống đó: nó gồm những container nào (ứng dụng, API, cơ sở dữ liệu, hàng đợi…) và các container giao tiếp với nhau ra sao. Muốn hiểu cách một request chạy xuyên hệ thống, bạn cần Level 2.

Vì sao chỉ mở cổng 443 và tắt cổng 80 trên production?

Theo hướng dẫn của tác giả, request từ Internet trước hết phải qua Cloudflare để chặn bot và request độc hại, sau đó đi vào hệ thống qua HTTPS cổng 443. Trên môi trường production, cổng HTTP 80 được tắt hẳn và chỉ để 443 — tức mọi kết nối đều phải là kết nối mã hóa qua cửa ngõ đã được bảo vệ, không còn đường vào phụ không mã hóa cho kẻ tấn công dò xét.

Gateway dùng Nginx hay Kong thì tốt hơn?

Kiến trúc mẫu đang chạy Nginx làm reverse proxy, và tác giả cho biết dùng Kong cũng được. Vai trò cốt lõi của Gateway ở Level 2 là định tuyến request theo subdomain vào đúng frontend/service bên trong (domain chính → User, admin → Admin, app → App, mcp → đường cho AI). Chọn Nginx hay Kong là quyết định triển khai; điều quan trọng ở tầng kiến trúc là hệ thống có một điểm vào duy nhất, rõ ràng, thay vì để từng service tự phơi ra Internet.

Queue (BullMQ) giải quyết bài toán gì?

Queue xếp hàng các tác vụ để xử lý lần lượt theo thứ tự đến trước – làm trước, thay vì bắt server xử lý tất cả cùng lúc. Theo cách ví von của tác giả: như quán gà rán có 100 khách vào cùng lúc, hàng đợi giúp hệ thống không sập khi tải đột biến, đồng thời có kỹ thuật để không làm mất tác vụ trong hàng đợi. Trong sơ đồ C4 Level 2, Queue là một container riêng, tách khỏi API xử lý request trực tiếp.

Thư mục Rules giúp AI không "vẽ lung tung" kiến trúc như thế nào?

Theo tác giả, thư mục Rules chứa toàn bộ quy trình phát triển phần mềm của dự án. Khi làm việc, AI tuân thủ các quy tắc đó, nên kiến trúc đã dựng được giữ nhất quán qua nhiều phiên dùng prompt, thay vì mỗi lần AI lại đề xuất một cấu trúc khác. Đây là cơ chế "khóa" kiến trúc ở tầng quy trình, bổ sung cho sơ đồ C4 — sơ đồ giúp con người đọc và kiểm chứng, Rules giúp AI làm đúng ngay từ đầu.

Kết luận

Đọc được sơ đồ Container Level 2 là đọc được toàn bộ hệ thống trong một hình: cửa ngõ Cloudflare, đường biên LAN nội bộ, Gateway chia luồng theo subdomain, Backend có API realtime và hàng đợi chống quá tải, tầng dữ liệu ba lớp PostgreSQL – MinIO – Redis, và Monitoring khóa kín ở cổng nội bộ để giám sát tất cả. Trong thời vibecoding, giá trị của sơ đồ này còn lớn hơn: nó là "bản đồ chuẩn" để đối chiếu mọi thứ AI sinh ra. Ai nắm được bản đồ thì dùng AI như công cụ; ai không, sẽ bị AI dắt mũi — và thư mục Rules là cách tác giả biến bản đồ đó thành luật mà AI phải tuân theo mỗi ngày.

Nguồn: bài hướng dẫn của trang Code Web Không Khó trên Facebook (09/11/2026) về cách đọc kiến trúc Container theo mô hình C4 Level 2, kèm sơ đồ hệ thống của tác giả; biên tập và hệ thống hóa bởi Wotech Electronics. Kiến trúc mẫu, lựa chọn công nghệ và các mẹo vận hành trong bài là theo chia sẻ của tác giả. Ảnh minh họa: ảnh đính kèm bài viết gốc.