Kiến trúc Hệ thống (System Architecture): Scalability & Security trong kỷ nguyên AI

Có một cuộc họp mà hầu như CTO nào cũng từng ngồi qua: 2 giờ sáng, hệ thống sập vì một chiến dịch marketing thành công ngoài dự kiến, đội vận hành đang restart service thủ công, còn CEO nhắn tin hỏi "bao giờ lên lại?". Điều trớ trêu là sự cố đó không sinh ra lúc 2 giờ sáng — nó được "đặt hàng" từ 18 tháng trước, trong một quyết định kiến trúc tưởng chừng nhỏ: nhét toàn bộ session, cache và business logic vào một tiến trình duy nhất, dùng chung một database, không có hàng đợi (queue), không có cơ chế co giãn.

Kiến trúc hệ thống là loại quyết định khó đảo ngược nhất trong đời một sản phẩm công nghệ. Bạn đổi màu nút bấm trong 5 phút, đổi giá trong một ngày, nhưng đổi từ một cơ sở dữ liệu quan hệ đơn khối sang mô hình phân tán có thể ngốn 6–12 tháng và vài lần suýt "chết lâm sàng". Câu hỏi mà mọi ban lãnh đạo hay đặt cho CPO/CTO không phải "kiến trúc này có đẹp không" mà là: "Nếu ngày mai lượng người dùng tăng 10 lần, hệ thống có sống được không, tốn thêm bao nhiêu, và dữ liệu khách hàng có an toàn không?".

Trong kỷ nguyên AI, câu hỏi đó nặng ký gấp đôi. Dữ liệu bùng nổ (vector embeddings, log hội thoại, tài liệu đưa vào RAG), chi phí tính toán biến động mạnh, và bề mặt tấn công (attack surface) mở rộng theo mỗi API bạn tích hợp với LLM. Bài này bàn về cách một CPO/CTO thiết kế kiến trúc cân bằng giữa scalability (khả năng mở rộng — hệ thống chịu tải tăng mà không sập, không đội chi phí phi tuyến) và security (an ninh — bảo vệ tính bí mật, toàn vẹn, sẵn sàng của dữ liệu), mà không rơi vào cái bẫy "over-engineering" đốt tiền cho một quy mô chưa bao giờ đến.

Trận chiến nền tảng: Monolith vs. Microservices

Đừng để hội thảo công nghệ đánh lừa: microservices (kiến trúc chia hệ thống thành nhiều dịch vụ nhỏ, độc lập, giao tiếp qua mạng) không phải là "phiên bản trưởng thành" của monolith (kiến trúc đơn khối, toàn bộ ứng dụng trong một codebase/tiến trình). Chúng là hai điểm khác nhau trên đường cong đánh đổi giữa tốc độ phát triển và chi phí vận hành.

Lời khuyên thực chiến cho SaaS Việt Nam giai đoạn đầu và giữa: bắt đầu bằng Modular Monolith — một khối duy nhất nhưng chia module rõ ràng theo domain (đúng như cách backend NestJS tổ chức mỗi feature thành một module có ranh giới), sẵn sàng "tách" khi có tín hiệu thật. Chỉ tách microservice khi gặp một trong ba tín hiệu: (1) một domain có nhu cầu scale hoàn toàn khác phần còn lại (ví dụ dịch vụ AI inference ngốn GPU); (2) tổ chức đã đủ nhiều team và ranh giới codebase gây tắc nghẽn deploy; (3) yêu cầu cô lập bảo mật/tuân thủ cho một khối dữ liệu nhạy cảm. Tách sớm vì "cho ngầu" là công thức tạo ra "distributed monolith" — thứ tệ nhất trong cả hai thế giới: phức tạp của phân tán mà không có lợi ích của tự chủ.

Các mẫu Scalability cốt lõi (nhớ đủ 3 chữ)

Scalability trong thực tế xoay quanh ba mẫu, kết hợp lại thành khung tôi hay gọi là S-C-Q:

1. Scaling (Horizontal scaling — mở rộng ngang): thêm nhiều bản sao (instance) của service phía sau load balancer thay vì "phình" một máy to hơn (vertical scaling). Điều kiện tiên quyết: service phải stateless — không giữ trạng thái phiên trong bộ nhớ tiến trình, mà đẩy session/cache ra store dùng chung (Redis). Không stateless thì không autoscale được.

2. Caching (bộ đệm): giảm tải cho database bằng cách đọc từ lớp nhanh. Ba tầng đáng nhớ: cache trình duyệt/CDN (nội dung tĩnh), cache ứng dụng (Redis cho dữ liệu đọc nhiều, đổi ít), và cache truy vấn. Nguyên tắc: đo hit rate; cache mà hit rate dưới 60–70% thường là đang giấu một vấn đề thiết kế truy vấn.

3. Queue (hàng đợi/bất đồng bộ): tách việc nặng ra khỏi luồng request bằng message queue (RabbitMQ) — gửi email, xử lý ảnh, chạy AI inference, đồng bộ dữ liệu. Queue vừa làm mượt đỉnh tải (buffer khi traffic tăng đột biến), vừa tăng độ bền (retry, dead-letter). Đây là "van xả áp" của mọi hệ thống chịu tải biến động.

Bổ sung cho tầng dữ liệu: read replica (bản sao chỉ đọc) để tách tải đọc/ghi, và sharding/partition khi một bảng vượt ngưỡng mà index không cứu được nữa. Nhưng nhớ thứ tự: tối ưu truy vấn và index trước, cache sau, replica sau nữa, sharding là biện pháp cuối vì nó làm phức tạp mọi thứ vĩnh viễn.

Bảo mật theo chiều sâu (Defense in Depth) & OWASP

An ninh không phải một bức tường mà là nhiều lớp phòng thủ, để khi một lớp thủng thì lớp sau vẫn giữ. Đây là Defense in Depth. Với một CPO/CTO, tối thiểu cần bảy lớp:

• Biên mạng (Edge): WAF, rate limiting, chống bot/DDoS (trong stack này Arcjet ở FE và rate limit ở gateway là ví dụ).
• Xác thực (AuthN): danh tính mạnh, MFA cho tài khoản nhạy cảm, quản lý phiên an toàn.
• Phân quyền (AuthZ): RBAC/ABAC, nguyên tắc least privilege — chỉ cấp quyền tối thiểu đủ dùng.
• Ứng dụng: validate mọi input (DTO + class-validator), chống injection, mã hoá output.
• Dữ liệu: mã hoá khi lưu (at rest) và khi truyền (in transit/TLS), tách khoá khỏi dữ liệu, tokenization cho dữ liệu nhạy cảm.
• Bí mật (Secrets): không hardcode; lấy từ Secrets Manager/SSM.
• Quan trắc (Observability): log truy cập, cảnh báo bất thường, audit trail (Sentry cho error tracking là một phần).

Neo tất cả vào OWASP Top 10 — danh sách 10 rủi ro bảo mật web phổ biến nhất do cộng đồng OWASP tổng hợp — như checklist tối thiểu: Broken Access Control, Cryptographic Failures, Injection, Insecure Design, Security Misconfiguration, Vulnerable Components, Auth Failures, Data Integrity Failures, Logging Failures, SSRF. Nếu đội chưa rà được 10 mục này thì mọi thảo luận về "zero trust" đều là xa xỉ.

Kiến trúc dữ liệu cho AI/LLM: bề mặt tấn công mới

Khi cắm LLM vào sản phẩm, bạn thêm một tầng kiến trúc và một loạt rủi ro mới. Thành phần điển hình của pipeline RAG (Retrieval-Augmented Generation — sinh câu trả lời dựa trên tài liệu truy hồi): nguồn dữ liệu → ingestion & chunking → embedding → vector database (như Qdrant trong stack này) → retrieval → prompt assembly → LLM → hậu kiểm output.

Ba nguyên tắc bảo mật AI mà CPO/CTO không được bỏ:

1. Cô lập dữ liệu theo tenant. Trong SaaS đa khách hàng, vector store phải mang metadata tenant và mọi truy vấn phải lọc theo tenant — nếu không, khách A có thể "truy hồi" nhầm tài liệu khách B. Đây là lỗi Broken Access Control phiên bản AI, cực kỳ khó phát hiện vì hệ thống vẫn "chạy đúng".
2. Phòng prompt injection. Coi mọi nội dung đưa vào prompt (kể cả tài liệu do người dùng upload) là input không tin cậy. Không để LLM tự ý gọi công cụ có quyền ghi mà không qua lớp kiểm duyệt.
3. Kiểm soát chi phí & rò rỉ. Đặt hạn mức token, log chi phí theo tenant, và không đẩy PII (thông tin định danh cá nhân) không cần thiết vào prompt gửi cho nhà cung cấp LLM bên thứ ba.

Phân tích theo 5W3H1R: "Thiết kế kiến trúc hệ thống có khả năng mở rộng & an toàn"

Why — Tại sao phải làm

Kiến trúc sai là loại nợ đắt nhất: nó không hiện ra trong sprint mà hiện ra trong sự cố (mất tiền, mất khách, mất niềm tin) và trong tốc độ giao hàng ngày càng chậm. Mục tiêu kinh doanh: đảm bảo hệ thống chịu được tăng trưởng (không phải rebuild giữa lúc scale), không sập vào lúc quan trọng nhất, và không để rò rỉ dữ liệu — thứ có thể xoá sổ cả một SaaS chỉ trong một sự cố. Giá trị tạo ra: đòn bẩy tăng trưởng với chi phí biên giảm dần, và niềm tin đủ để bán được cho khách hàng lớn (enterprise luôn hỏi về bảo mật trước khi ký).

What — Bản chất là gì (chi tiết nhất)

Là việc định nghĩa bản thiết kế tổng thể cho cách hệ thống được chia thành các thành phần, cách chúng giao tiếp, cách dữ liệu chảy, cách hệ thống co giãn theo tải, và cách bảo vệ theo nhiều lớp.

• Scope IN: ranh giới service (bounded context), mô hình dữ liệu & chiến lược lưu trữ (SQL/NoSQL/vector), chiến lược scaling (stateless + autoscale + queue + cache), kiến trúc bảo mật 7 lớp, kiến trúc AI/RAG, quan trắc (logging/metrics/tracing), chiến lược phục hồi (backup, RTO/RPO — thời gian và mức mất dữ liệu chấp nhận được).
• Scope OUT: chi tiết triển khai từng feature, tối ưu vi mô từng dòng code, lựa chọn thư viện nhỏ — thuộc về đội thực thi, không phải quyết định kiến trúc.
• Thành phần cấu thành: (1) sơ đồ kiến trúc C4 (Context–Container–Component); (2) Architecture Decision Records (ADR — nhật ký quyết định kiến trúc có lý do và đánh đổi); (3) mô hình đe doạ (threat model); (4) NFR — yêu cầu phi chức năng (tải mục tiêu, độ trễ p95, uptime SLA).
• Output/sản phẩm đầu ra: bộ tài liệu ADR + sơ đồ C4 + threat model + runbook sự cố + bảng NFR đã được ký duyệt.

Who — Ai làm & ai hưởng lợi (RACI)

• A (Accountable): CTO/CPO — chịu trách nhiệm cuối về quyết định kiến trúc và đánh đổi.
• R (Responsible): Kiến trúc sư/Tech Lead + đội Platform/DevOps + Security engineer.
• C (Consulted): trưởng các nhóm feature, DBA, đại diện Product (ràng buộc lộ trình), Legal/Compliance (dữ liệu).
• I (Informed): CEO/ban điều hành, Customer Success (để trả lời khách về bảo mật), toàn đội kỹ thuật.
• Hưởng lợi: khách hàng (dịch vụ ổn định, dữ liệu an toàn), đội bán hàng (bán được cho enterprise), tài chính (chi phí hạ tầng dự đoán được).

Where — Diễn ra ở đâu

Trên toàn bộ hệ sinh thái SellersStar: tầng biên (CDN/WAF/gateway), tầng ứng dụng (các module NestJS backend, frontend Next.js), tầng dữ liệu (MySQL, Redis, vector Qdrant), tầng bất đồng bộ (RabbitMQ), tầng AI (LLM providers + RAG), và tầng hạ tầng (AWS qua Terraform — VPC, ECS, RDS, S3, monitoring). Phạm vi áp dụng: mọi service mới đều phải qua "cổng kiến trúc" (architecture review) trước khi được cấp hạ tầng.

When — Khi nào bắt đầu & kết thúc

Kiến trúc là hoạt động liên tục có nhịp, không phải dự án một lần.

• Khởi động: ngay khi định hình sản phẩm (chọn Modular Monolith, đặt nền stateless + queue + cache từ đầu).
• Nhịp review: ADR review theo từng quyết định lớn; architecture review hằng quý; threat model làm mới mỗi khi thêm bề mặt tấn công (tích hợp mới, LLM mới); "war game"/tabletop sự cố 6 tháng/lần.
• Điểm tái cấu trúc: kích hoạt khi chạm ngưỡng NFR (ví dụ p95 vượt mục tiêu, chi phí/đơn vị tăng phi tuyến).

How — Quy trình các bước (đánh số)

Bước 1 — Xác định NFR & ràng buộc.
Đầu vào: mục tiêu kinh doanh, dự báo tăng trưởng, yêu cầu tuân thủ. Hoạt động: lượng hoá tải mục tiêu (RPS, đồng thời), độ trễ p95/p99, uptime SLA, RTO/RPO, ngân sách hạ tầng. Đầu ra: bảng NFR ký duyệt.

Bước 2 — Vẽ sơ đồ hiện trạng & mục tiêu (C4).
Đầu vào: NFR + hệ thống hiện có. Hoạt động: mô hình hoá Context → Container → Component; xác định bounded context. Đầu ra: sơ đồ C4 + danh sách service.

Bước 3 — Chọn kiểu kiến trúc & đánh đổi.
Đầu vào: sơ đồ + quy mô đội. Hoạt động: quyết định Monolith vs Microservice cho từng domain bằng ma trận đánh đổi; ghi ADR. Đầu ra: ADR với lý do & phương án loại bỏ.

Bước 4 — Thiết kế scalability (S-C-Q).
Đầu vào: điểm nóng tải. Hoạt động: stateless hoá service, đặt Redis cache, chèn RabbitMQ cho việc nặng, cấu hình autoscale + load balancer, lên chiến lược read replica. Đầu ra: bản thiết kế scaling + kịch bản load test.

Bước 5 — Thiết kế bảo mật (Threat Model + 7 lớp).
Đầu vào: sơ đồ + luồng dữ liệu. Hoạt động: chạy STRIDE, rà OWASP Top 10, thiết kế 7 lớp phòng thủ, đặt quản lý secrets, mã hoá at rest/in transit. Đầu ra: threat model + checklist bảo mật + kế hoạch xử lý.

Bước 6 — Thiết kế tầng dữ liệu & AI.
Đầu vào: nhu cầu dữ liệu & AI. Hoạt động: chọn store (SQL/NoSQL/vector), thiết kế cô lập tenant, pipeline RAG, kiểm soát chi phí LLM. Đầu ra: data architecture + AI guardrails.

Bước 7 — Thiết lập quan trắc & phục hồi.
Đầu vào: kiến trúc đã chốt. Hoạt động: logging/metrics/tracing, alert, backup, viết runbook sự cố. Đầu ra: dashboard + runbook + kế hoạch DR.

Bước 8 — Kiểm chứng & lặp.
Đầu vào: hệ thống đã dựng. Hoạt động: load test, penetration test, chaos test nhẹ, tabletop; đối chiếu NFR. Đầu ra: báo cáo kiểm chứng + backlog cải tiến, quay lại Bước 1 theo nhịp.

How Much — Cần bao nhiêu nguồn lực

Định tính theo mức: nhân sự — tối thiểu một Tech Lead/kiến trúc sư dẫn dắt, đội DevOps/Platform (mức nhỏ ở giai đoạn đầu, tăng khi tách microservice), và năng lực security (part-time/thuê ngoài audit ở giai đoạn đầu là hợp lý). Ngân sách hạ tầng — mức thấp và tuyến tính nếu giữ Modular Monolith; tăng đáng kể khi thêm observability stack, service mesh, và GPU cho AI. Thời gian lãnh đạo — kiến trúc đòi hỏi CPO/CTO đầu tư đều đặn, không uỷ thác hết. Nguyên tắc: đầu tư theo tín hiệu thật, đừng mua "hạ tầng cho quy mô tưởng tượng".

How Long — Bao lâu thấy kết quả

• Quick win (2–6 tuần): stateless hoá + cache + queue thường cải thiện độ ổn định và độ trễ thấy rõ ngay.
• Trung hạn (1–3 tháng): hoàn thiện 7 lớp bảo mật, threat model, quan trắc — giảm rõ số sự cố và thời gian phục hồi.
• Dài hạn (6–12 tháng): tách microservice cho domain nóng, sharding — chỉ khi có tín hiệu. Đây là công việc liên tục: mỗi quý là một vòng đo–điều chỉnh, không có vạch đích.

Risk — Rủi ro & phương án dự phòng

Khung mô hình: Ma trận quyết định kiến trúc "Scalability × Security"

Để tránh tranh cãi cảm tính, tôi dùng một khung định vị mức đầu tư theo hai trục: mức độ trọng yếu của dữ liệu (rò rỉ gây thiệt hại tới đâu) và mức độ biến động tải (traffic bùng nổ tới đâu).

Ô góc dưới-phải là nơi đội của bạn phải "chín" nhất — và cũng là nơi phần lớn SaaS B2B Việt Nam sẽ tiến tới khi bán cho khách hàng lớn.

Framework áp dụng ngay: Architecture Review Checklist

Copy dùng cho mỗi lần review kiến trúc một service/tính năng mới trước khi cấp hạ tầng.

[ ] NFR: đã có tải mục tiêu (RPS/đồng thời), p95, uptime SLA, RTO/RPO?
[ ] Sơ đồ C4 (ít nhất Container level) đã cập nhật?
[ ] ADR đã ghi quyết định + phương án loại bỏ + đánh đổi?
[ ] Service có stateless không? Session/cache đẩy ra Redis?
[ ] Việc nặng/chậm đã đẩy sang RabbitMQ (async) chưa?
[ ] Chiến lược cache rõ ràng? Có đo hit rate?
[ ] DB: index đủ chưa? cần read replica? có nguy cơ N+1?
[ ] Bảo mật: rà đủ OWASP Top 10 chưa?
[ ] AuthZ theo least privilege? RBAC/ABAC rõ ràng?
[ ] Mã hoá at rest + in transit? Secrets nằm ở Secrets Manager?
[ ] Đa tenant: dữ liệu cô lập chặt? Vector store filter theo tenant?
[ ] AI/LLM: guardrail prompt injection? hạn mức token? không lộ PII?
[ ] Quan trắc: log + metrics + trace + alert đã có?
[ ] Backup tự động + đã test restore? Có runbook sự cố?
[ ] Single point of failure đã nhận diện & xử lý (redundancy)?
[ ] FinOps: ước tính chi phí + budget alert theo service?
[ ] Kế hoạch load test / pen-test trước khi go-live?

Case study Việt Nam (minh hoạ điển hình)

Ghi chú: case minh hoạ điển hình, không phải số liệu nội bộ của một công ty có thật.

Bối cảnh. Một SaaS quản lý bán hàng B2B tại TP.HCM, ~40 người, phục vụ các nhà bán lẻ và chuỗi cửa hàng. Khởi đầu bằng một monolith "vô kỷ luật": mọi thứ trong một app, session lưu trong bộ nhớ, tất cả job (gửi thông báo, xuất báo cáo, đồng bộ đơn) chạy đồng bộ trong luồng request, một database gánh cả đọc lẫn ghi. Ổn khi vài trăm khách. Đến mùa cao điểm (khuyến mãi lớn của các cửa hàng), traffic tăng vọt, hệ thống sập nhiều lần vì báo cáo nặng khoá cả DB; đồng thời một đợt rà soát bảo mật của khách hàng enterprise phát hiện API thiếu phân quyền chặt và secrets nằm ngay trong biến môi trường plaintext — suýt mất một hợp đồng lớn.

Can thiệp (theo đúng quy trình 8 bước). Đội không đập đi xây lại. Họ giữ Modular Monolith nhưng: (1) stateless hoá app, đẩy session/cache sang Redis, bật autoscale sau load balancer; (2) đưa toàn bộ job nặng (báo cáo, thông báo, đồng bộ) sang hàng đợi để tách khỏi luồng request; (3) thêm read replica cho các truy vấn báo cáo; (4) rà OWASP Top 10, siết RBAC theo least privilege, chuyển secrets sang Secrets Manager, bật mã hoá in transit; (5) thêm quan trắc + alert + runbook. Sau đó, khi thêm trợ lý AI tra cứu tài liệu bán hàng, họ tách riêng service AI (cô lập tài nguyên và bảo mật), dùng vector store có filter theo tenant.

Kết quả (định tính, minh hoạ). Hệ thống trụ được qua mùa cao điểm mà không sập; độ trễ ở các thao tác chính giảm rõ nhờ cache + async; số sự cố ban đêm giảm mạnh vì báo cáo không còn khoá DB. Quan trọng nhất về mặt kinh doanh: vượt qua vòng đánh giá bảo mật và ký được hợp đồng enterprise — đúng cái đòn bẩy doanh thu mà kiến trúc tốt mở ra. Bài học: phần lớn giá trị đến từ những mẫu cơ bản (stateless, cache, queue, least privilege, secrets) làm đúng — chứ không phải từ việc nhảy sang microservice.

GÓC NHÌN CPO/CTO

• Nếu ngày mai người dùng tăng 10 lần, điểm nào trong hệ thống sập đầu tiên — và tôi có đang đo nó không, hay chỉ đang đoán?
• Quyết định kiến trúc nào chúng tôi đang trì hoãn vì "chưa cần", mà nếu sai sẽ mất 6–12 tháng để đảo ngược?
• Nếu một kỹ sư bị lộ credential ngay bây giờ, phạm vi thiệt hại rộng đến đâu — least privilege của chúng tôi thật hay chỉ trên giấy?
• Chúng tôi đang chi bao nhiêu cho độ phức tạp (microservice, hạ tầng) mà thực tế chưa cần đến quy mô đó?
• Với mỗi tích hợp AI/LLM mới, chúng tôi có cập nhật threat model, hay chỉ ghép API rồi cầu nguyện?

🔗 Liên kết với các bài khác (Alignment)

• Kiến trúc là hiện thân kỹ thuật của tầm nhìn sản phẩm — bắt đầu từ PT-01 Product Vision & Strategy.
• Mỗi quyết định kiến trúc chưa tối ưu là một khoản nợ; quản lý nó ở PT-07 Quản lý Nợ Kỹ thuật (Tech Debt).
• Kiến trúc dữ liệu tốt là nền cho phân tích và đo lường sản phẩm: PT-08 Data-Driven Product Management.
• SDLC tinh gọn quyết định nhịp bạn đưa thay đổi kiến trúc ra an toàn: PT-03 Quy trình Phát triển Sản phẩm (SDLC) tinh gọn.
• Kiến trúc mở (API) là điều kiện để thực thi chiến lược đối tác: OPS-03 Chiến lược Đối tác (API mở).
• Độ ổn định hệ thống trực tiếp ảnh hưởng trải nghiệm và giữ chân khách: OPS-05 Customer Success.
• Trải nghiệm mượt mà mà UX hứa hẹn phải được kiến trúc "đỡ" phía sau: PT-05 User Experience (UX) cho SaaS.

Kết bài

Kiến trúc là nơi CPO/CTO tạo ra hoặc phá huỷ đòn bẩy dài hạn của doanh nghiệp. Không có kiến trúc "đúng" tuyệt đối — chỉ có kiến trúc phù hợp với quy mô hiện tại và sẵn sàng cho quy mô kế tiếp, cân bằng giữa tốc độ giao hàng, chi phí vận hành, khả năng mở rộng và an ninh. Cái bẫy lớn nhất không phải là chọn công nghệ sai, mà là hoặc over-engineering đốt tiền cho quy mô tưởng tượng, hoặc under-invest để rồi trả giá bằng một đêm mất ngủ và một hợp đồng tuột mất.

Hành động tuần này: lấy Architecture Review Checklist ở trên, chấm điểm service quan trọng nhất của bạn, và mở một ADR cho quyết định kiến trúc lớn mà bạn đang trì hoãn. Kiến trúc tốt không phải là bản vẽ hoàn hảo — nó là chuỗi quyết định có ghi chép, đo được và đảo ngược được ở mức tối đa có thể.

Bài trước: User Experience (UX) cho SaaS · Bài tiếp theo: Quản lý Nợ Kỹ thuật (Tech Debt)